I wish to write a terminal emulator in Python. I am a fairly competent
Python user, and I wish to try a new project idea. What references can I
use when writing my terminal emulator? I wish for it to be a true
terminal emulator as well, not just a Tk text widget or something like that.

If you have any advice, please do let me know!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 14.05.24 um 19:44 schrieb Gordinator via Python-list:

I wish to write a terminal emulator in Python. I am a fairly
competent Python user, and I wish to try a new project idea. What
references can I use when writing my terminal emulator? I wish for
it to be a true terminal emulator as well, not just a Tk text widget
or something like that.

If you have any advice, please do let me know!

Not sure, what you mean with:

true terminal emulator as well, not just a Tk text widget or something like that

If you want to write a GUI terminal, than that *is* a terminal
emulator and *has* a text widget as its visible core. If you want to
write something like getty which runs on the virtual terminals
(Ctrl+Alt+F*) than that is a terminal (not a terminal emulator).

In both cases, you write something that gets input from the
keyboard, processes it and shows the result. How that processing is
done, depends on the terminal standard, like DEC VT{100, 102, 220,
320, etc}.

For a start, you might want to look at Terminator, which is a
terminal emulator written in Python, Gtk and libvte (which does all
the low level stuff).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14May2024 18:44, Gordinator <gordinator@gordinator.org> wrote:

I wish to write a terminal emulator in Python. I am a fairly competent
Python user, and I wish to try a new project idea. What references can
I use when writing my terminal emulator? I wish for it to be a true
terminal emulator as well, not just a Tk text widget or something like
that.

Start with the `pty` module.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Gordinator <gordinator@gordinator.org> wrote or quoted:

I wish to write a terminal emulator in Python.

We need somethin like a portable curses module (plus colorama)
and it has got to work on both Windoze and Linux straight out
of the box in standard Python. And it would be even sicker if it
could run in that IDLE console too! That way, we could code up
some legit terminal-based software (like slrn or Nethack) using
just plain ol' Python, no extra stuff required. It's a real
shame it ain't already part of the standard library. Someone's
got to step up and make this happen. Python needs a portable
console TUI! It'd be the bomb if you could make /that/ happen!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

We need somethin like a portable curses module (plus colorama)

Agreed, getting curses to work on Windows is SUCH a pain, and I don't
think I've ever done it. Naturally, as a Linux user, I don't find much
need to do it anyway.

Colorama would also be cool in the standard library as well. I have
worked on projects in the past where only the standard library could be
used, so I 100% agree with this. But that's something for the PSF to
talk about. Maybe someone could write a PEP for this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15 May 2024 10:31:25 GMT, Stefan Ram wrote:

We need somethin like a portable curses module (plus colorama) and
it has got to work on both Windoze and Linux straight out of the box
in standard Python.

Something else for Windows Python users to complain that they cannot get
to install properly?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/05/2024 01:12, Lawrence D'Oliveiro wrote:

On 15 May 2024 10:31:25 GMT, Stefan Ram wrote:

We need somethin like a portable curses module (plus colorama) and
it has got to work on both Windoze and Linux straight out of the box
in standard Python.

Something else for Windows Python users to complain that they cannot get
to install properly?

To be fair, the problem is the fact that they use Windows (but I guess
Linux users have to deal with venvs, so we're even.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 16 May 2024 19:46:07 +0100, Gordinator wrote:

On 16/05/2024 01:12, Lawrence D'Oliveiro wrote:

On 15 May 2024 10:31:25 GMT, Stefan Ram wrote:

We need somethin like a portable curses module (plus colorama) and it
has got to work on both Windoze and Linux straight out of the box in
standard Python.

Something else for Windows Python users to complain that they cannot
get to install properly?

To be fair, the problem is the fact that they use Windows (but I guess
Linux users have to deal with venvs, so we're even.

Linux users get to have standard packages for systemwide installs. You
only need virtual envs for custom setups.

Even nonstandard systemwide installs are nicely contained in /usr/local,
so they are easy to remove.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-14 22:37:17 +0200, Mirko via Python-list wrote:

Am 14.05.24 um 19:44 schrieb Gordinator via Python-list:

I wish to write a terminal emulator in Python. I am a fairly competent Python user, and I wish to try a new project idea. What references can I use when writing my terminal emulator? I wish for it to be a true
terminal emulator as well, not just a Tk text widget or something like that.

If you have any advice, please do let me know!

Not sure, what you mean with:

true terminal emulator as well, not just a Tk text widget or
something like that

If you want to write a GUI terminal, than that *is* a terminal emulator and *has* a text widget as its visible core. If you want to write something like getty which runs on the virtual terminals (Ctrl+Alt+F*) than that is a terminal (not a terminal emulator).

Getty isn't a terminal (unless there is another program of the same
name). It's a small program to set up a serial communication line.
Basically it waits for the modem to connect, sets the relevant
parameters (bit rate, byte width, parity, ...) and then hands over to
login. Of course in the case of a linux console there is no modem and no
serial line involved, so it doesn't have much to do. (Of course this
raises the question whether the Linux console is a terminal or a
terminal emulator ...)

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmZIxn4ACgkQ8g5IURL+ KF1R7w/+PRClvT91X3cljL3XcYEfbLmeI+un/FeX/oZtsYTQLr6Qn91hOZxLRS93 LPA6+/xfoxjqhQtuami7X1L1BA1/EWpdmE9BSAQUSzqGVWEIA++pizIjk+b3pC7o pyfiu3K2qfQ5dIkQMlq8xUWJIDgCc/YJan6Lf0gAdrGI0bvKSIiwTv4wS2Un9F6b B5fa/3HHdQeX6SWe600wwzrox+uOUyOXTuToDkFQtgZN6TzPKrFfLXP3SnKsnI4R EVMCbTIISg9WLOLptDwQPgYs4BA+AGpNgG5wVGIRmlm22j2V8RfVKmh3AoQGxEM9 6EJnF8zd24SHCvPTP0U4Xrtp8ER4B0gab3PYrynQUDLLqJYKxg5V9NmldXs4sFO8 HTiOyCLbl79836ykcMfosPxVKKn2JBqtGR86KXwuYNjIfj1lGX6xcRkL8l9fpJwk SCLWBu1FymzEbdbf7UVNnFK8+N9YZG1nMtwkqvItdtM4bi3tQ6AipCzwBdTh6SWy pUDEEMxbiwqnSCL+FC0lkjDXEYptVCqM5bekrKlKa8QHW1WpWeEM7YoE7aXk1qXM bV1LMJz+Q6OwV03TGBa3tvd5H0cldh0H4NZNrPXHIVGbs1N7/jcEj+fzwDZc4c8z vsQn6iMC5QRqd9ozKaj6hzluM+GX9UFBZ6192uI

On 2024-05-14 16:03:33 -0400, Grant Edwards via Python-list wrote:

On 2024-05-14, Alan Gauld via Python-list <python-list@python.org> wrote:

On 14/05/2024 18:44, Gordinator via Python-list wrote:

I wish to write a terminal emulator in Python. I am a fairly
competent Python user, and I wish to try a new project idea. What
references can I use when writing my terminal emulator? I wish for
it to be a true terminal emulator as well, not just a Tk text
widget or something like that.

The first thing is to decide which terminal.

If you want to make life easier, make it a superset of a terminal that already exists in the terminfo database.

Going with some sort of ANSI terminal will probably provide
operability even with dumb apps which ignore $TERM and just spit out
basic ANSI escape sequences.

And if you want to go for a superset, xterm might be one of the more
useful: https://www.xfree86.org/current/ctlseqs.html

If you really want to break trail, you could invent your own control sequences, which means you'll have to write terminfo and/or termcap
entries as well as the terminal emulator.

Right. A saner model than ANSI and its supersets might be a good idea conceptionally. But I'd expect quite a few programs to break.

A VT100 is very different from a 3270. And even a VT330 is quite
different from a VT100 although sharing a common subset of control
codes. And if you start looking at graphical terminals things get
even more interesting!

"Intersting" is putting it mildly...

Yup. Also there aren't many programs which use, e.g. xterm's
pixel-graphics capabilities.

OTOH, there is something like domterm[1], which can (theoretically)
display anything a browser can display.

hp


[1] https://domterm.org/index.html

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmZIxHYACgkQ8g5IURL+ KF0IXBAAoQFTpO6zc9CUgW9Y3wWpzyrQeSV1HlsVu8XnfMbIQV/8oUxzVzDZN0pA r9nKVvgvPoFinDZAZllmhkvQD4OfpVtjQyt9Wwo57XjQrL/KFPBe7k6JI0owmZ6T ZWwV5vLKjEBSGUkVsHm+t8uoV0ANgnUXZraKY/72BksefxeubnSg42SzmDBZMHrw xxUOlHNmgbHvsYQACdA/EIQIimL+czAXRnN6JcbHoMYTJb6oBLnIPtUUQMGJsEev gjnRWPpdqM6lPJdvsahkUrhuPtsNMncWYG5BxWQw6atcV0+7Yat4n8uKh9ZGKqPq lVzXSwsHgRCFFz+PCkSl8dJKmhttlKZOrqa6ApmfJSnrEMbevaVcRrIeO59ObtM4 S9zx7vFJRgc0mRm33Pa/I8/5DY48vB+qukBubOmHPC6tgMbrea7M45/Zsw031Y/1 mOeaG5IFhCJ4hTnCmXmSPoqr01/0QTQk979u7Vq+E7AJSp1vXT6hh/I6VuMGtFFi YVvnp+BiRmIZLFazw07m5pUsg6cLFMZL5vztQC2354r2Felre3UO2rJV8ZGGbKVT a6VelL6zDzVAmoaNuASPJwV484A9Pvq001x0YaSV/5CIoNwaMoYACW8yD5UoQzEC ZLbfhp6VqsP04D+bIGnfVeqlvrcDmsEywVqrk9k

On 2024-05-16 19:46:07 +0100, Gordinator via Python-list wrote:

To be fair, the problem is the fact that they use Windows (but I guess Linux users have to deal with venvs, so we're even.

I don't think Linux users have to deal with venvs any more than Windows
users. Maybe even less because many distributions come with a decent
set of Python packages.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmZIxvEACgkQ8g5IURL+ KF286g//VSd8f1UAzp3SQfki8kvsbf0u/nRQdfAq/M/yDlZmlAFOaFp6V2r/OCXI XQhAtF4uei7MIcnc6ZJ6nID/29j+vRic2bnr36KpwmX3FDFreI8Rs+Uf1xQ2csvs mIcfqJd5FvC/VkOOuP2vPrkZPtkpD0BpJe1QOB2QwXYWB8MUzgfZBnNwsfgH1nJ6 xwaQpApg6b0BdsPC4YW76Q4roK8Fbm/K9QmngXNQIIbj1KTzJQXyt6VlZZfa0PLK hroWRHgCtEyR7KSx9pmC+Qc+PZFo3ymNSEaeFm54wce8IM8Tl5cyra4kAAHV51IQ AZtajXiOwIB8R/fSvH+Y5R8CPogFC2B8wfV28rJlMqWcPZImQtuIjNlXK6CKdaSU FAK7oZdcyBx6a/Pafx2BvtQ0aEcClWqOautgNcBjnUFP1Ic17cSsreu3BZxGAv8a 58/8CsgKzOk7aAORewTxcUk3J/3xlL5LXwxxUzE7w8vr0R/B3ONUOg5JNj8IE2iD n3DQZZE/FfnviFbMN7bEGl8bii019n+Zmfv3Fh/6ndOHcxooqlUhov7Tt5l8qjNL D9xvPydjZPT3iv399yeO9LlswWhQNN/GX1IDFlLcR1rQtqg1fV8v3pHHXde2j65J fxEm6yGsThyNpki2fdHht8lGVv70/gNPYBXA+8K

On 14/05/2024 19.44, Gordinator wrote:

I wish to write a terminal emulator in Python. I am a fairly competent
Python user, and I wish to try a new project idea. What references can I
use when writing my terminal emulator? I wish for it to be a true
terminal emulator as well, not just a Tk text widget or something like
that.

If you have any advice, please do let me know!

I would start writing down what this
"terminal emulator" should do.

Then, collect information about what
module / library can support the features.

bye,

--

piergiorgio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/18/24 10:48, Grant Edwards via Python-list wrote:

On 2024-05-18, Peter J. Holzer via Python-list <python-list@python.org> wrote:

On 2024-05-16 19:46:07 +0100, Gordinator via Python-list wrote:

To be fair, the problem is the fact that they use Windows (but I
guess Linux users have to deal with venvs, so we're even.

I don't think Linux users have to deal with venvs any more than
Windows users. Maybe even less because many distributions come with
a decent set of Python packages.

I've been using Python on Linux almost daily for 25 years,

same here, but:

and I've

yet to use a venv...

Distros have do offer a good selection of packaged Python bits, yes, but
only for the version of Python that's "native" to that distro release.
If you need to test other versions of Python, you're mostly on your own.
Just as an example, for a particular project I had one test machine
running Fedora 38 until just a couple weeks ago, with Python 3.11 as
"native" with a full suite of packages, but I needed to test 3.12 and
then the 3.13 pre-releases, as well as occasionally sanity-check the
"oldest supported Python for this project", which turned out to be 3.6.
I could build all those Pythons myself and install them to a location I
can "python3.xx -m pip install" to, but Fedora is nice enough to package
up a whole bunch of past and future Python versions, so why? And Fedora
really discourages doing installs via pip to a system-packaged Python.
So venvs make managing all that pretty convenient. Dunno why everybody's
so down on venvs...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/05/2024 20.04, Mats Wichmann wrote:
[...]

So venvs make managing all that pretty convenient. Dunno why everybody's
so down on venvs...

Only people which are *not* using python... :-)

In my experience, venvs is the only possible
way to use python properly.

The dependency nightmare created by python, pip
and all the rest cannot be resolved otherwise.

It seems backward compatibility is a taboo...

bye,

--

piergiorgio

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/19/2024 3:32 AM, Alan Gauld via Python-list wrote:

On 18/05/2024 19:12, Piergiorgio Sartor via Python-list wrote:

[snip]

The dependency nightmare created by python, pip
and all the rest cannot be resolved otherwise.

I've honestly never experienced this "nightmare".
I install stuff and it just works.

One way it can bite even you is if you have a program installed whose requirements claim it needs a certain library of version no higher than
X, and you already already have a later version of that library
installed since one of your other programs requires it. Pip won't
install the new program because of this conflict.

In reality, you may know the the new program would work fine with the
version of the library you installed, but the packagers of the new
program didn't realize they should have updated their requirements.

With venvs, you can have separate environments for each. Of course this doesn't help if you need both packages in the same environment...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 19 May 2024 08:32:46 +0100, Alan Gauld wrote:

I've honestly never experienced this "nightmare".
I install stuff and it just works.

Hear! Hear! Me too! And all that.

I'm on Manjaro, which is a tad finicky about other people touching its
Python since it's used for lots of things. I install things for myself
only.

Was there a reason they chose the name Pip?

From WordNet (r) 3.0 (2006) [wn]:

pip
n 1: a disease of poultry
2: a minor nonspecific ailment
3: a small hard seed found in some fruits
4: a mark on a die or on a playing card (shape depending on the
suit) [syn: {spot}, {pip}]
5: a radar echo displayed so as to show the position of a
reflecting surface [syn: {blip}, {pip}, {radar target}]
v 1: kill by firing a missile [syn: {shoot}, {pip}]
2: hit with a missile from a weapon [syn: {shoot}, {hit}, {pip}]
3: defeat thoroughly; "He mopped up the floor with his
opponents" [syn: {worst}, {pip}, {mop up}, {whip}, {rack up}]

--
Gilmeh

All the evidence concerning the universe has not yet been collected, so
there's still hope.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-19 at 18:13:23 +0000,
Gilmeh Serda via Python-list <python-list@python.org> wrote:

Was there a reason they chose the name Pip?

Package Installer for Python

https://pip.pypa.io/en/stable/index.html

Every time I see PIP, I think Peripheral Interchange Program, but I'm
old.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-19 19:13, Gilmeh Serda via Python-list wrote:

On Sun, 19 May 2024 08:32:46 +0100, Alan Gauld wrote:

I've honestly never experienced this "nightmare".
I install stuff and it just works.

Hear! Hear! Me too! And all that.

I'm on Manjaro, which is a tad finicky about other people touching its
Python since it's used for lots of things. I install things for myself
only.

Was there a reason they chose the name Pip?

[snip]
From https://pip.pypa.io/en/stable/:

"pip is the package installer for Python."

It's an acronym.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-19 at 18:13:23 +0000,
Gilmeh Serda via Python-list <python-list@python.org> wrote:

Was there a reason they chose the name Pip?

Package Installer for Python

https://pip.pypa.io/en/stable/index.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <python-list@python.org> wrote:

I don't think Linux users have to deal with venvs

Modern debian (ubuntu) and fedora block users installing using pip.
You must use a venv to pip install packages from pypi now.
This is implemented in python and pip and enabled by the distros.

There are ways to turn off the blocking, but it’s strongly discouraged
by the distros.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, May 19, 2024 at 10:45:09PM +0100 schrieb Barry via Python-list:

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <python-list@python.org> wrote:

I don't think Linux users have to deal with venvs

Modern debian (ubuntu) and fedora block users installing using pip.
You must use a venv to pip install packages from pypi now.

Which makes one wonder how one is supposed to package Python
applications requiring modules not yet packaged by Debian.

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08:

Modern debian (ubuntu) and fedora block users installing using pip.

Even if you're telling it to install in ~/.local? I could see not allowing
to run it as root.

I assumed pip install --user would work, but no. I tried it (on Debian
12 (bookworm)):

$ pip install --user docopt
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,     it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at
the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Exactly the same output for sudo pip install.

For easy reference here's a link to that PEP 668: https://peps.python.org/pep-0668/
Which links to the "Externally Managed Environments" on the PyPA specs
page: https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments

--
"If you don't read the newspaper, you're uninformed. If you read the newspaper, you're mis-informed."
-― Onbekend (dikwijls toegeschreven aan Mark Twain, waarschijnlijk onterecht)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/19/2024 6:08 PM, Skip Montanaro via Python-list wrote:

Modern debian (ubuntu) and fedora block users installing using pip.

Even if you're telling it to install in ~/.local? I could see not allowing
to run it as root.

I honestly haven't tried. Maybe I should... 🤔 I have an old laptop running XUbuntu 22.04 which I generally only use to compile the most recent
branches on GitHub (main, 3.12, & 3.13 at the moment).

On some (maybe all) of my Linux VMs, pip - the one installed for the
system - won't install something even with --user unless you use the --break-system-packages flag.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/19/2024 6:34 PM, Grant Edwards via Python-list wrote:

On 2024-05-19, Barry via Python-list <python-list@python.org> wrote:

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <python-list@python.org> wrote:

I don't think Linux users have to deal with venvs

Modern debian (ubuntu) and fedora block users installing using pip.

You can't even use pip to do "user" installs?

Nope, often not. The error messages I've gotten do tell you to use the "--break-system-packages" flag if you really, really want to install the package. So

python3 -m pip install --user --break-system-packages [--upgrade]
<package name>

Or install an additional version of Python that isn't managed by the system.

Grant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/19/2024 6:00 PM, Karsten Hilbert via Python-list wrote:

Am Sun, May 19, 2024 at 10:45:09PM +0100 schrieb Barry via Python-list:

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <python-list@python.org> wrote:

I don't think Linux users have to deal with venvs

Modern debian (ubuntu) and fedora block users installing using pip.
You must use a venv to pip install packages from pypi now.

Which makes one wonder how one is supposed to package Python
applications requiring modules not yet packaged by Debian.

I confess, I sometimes install those packages using pip's self-warning
option "--break-system-packages". Naturally I only install them with
--user. Another option besides venvs is to install a different version
of Python from python.org, not by using the system installer. For
example, if your system version is, say, 3.8.10 (as it is on my Mint
VM), install 3.11.9 and make sure you always launch pip with

python3.11 -m pip ....

I have done this on some VMs, and use the system's Python on some
others. Happily none of my Linux VMs are critical for anything. I can
blow them away and recreate them without worry.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-20 00:26:03 +0200, Roel Schroeven via Python-list wrote:

Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08:

Modern debian (ubuntu) and fedora block users installing using pip.

Even if you're telling it to install in ~/.local? I could see not allowing to run it as root.

I assumed pip install --user would work, but no. I tried it (on Debian 12 (bookworm)):

$ pip install --user docopt
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make     sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,     it may be easiest to use pipx install xyz, which will manage a     virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Exactly the same output for sudo pip install.

This message (quoted in all its glory) is too long to be useful. The
important bit is at the end:

You can override this, at the risk of breaking your Python
installation or OS, by passing --break-system-packages.

(I admit I didn't see this the first time I got this message)

python3 -m pip install --user --break-system-packages <packagename>
does indeed install into ~/.local/lib/python3.XX/site-packages.

This inconvenient, but otoh I have accidentally installed packages into ~/.local in the past, so maybe it's good to make that more explicit.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmZLHt8ACgkQ8g5IURL+ KF07XBAAq48dvDkUSxUF0J2AvUifs3/IK18GqpR8xPl+OFxE4123K9Susnxk1NE5 w+4ZzuQO8NAt5YR+BgfR28yRJWMBGS67VX8y+LujHjohr9Fj8r/KpUr6Az/WsjdL nU1DemQxQV3T7tO0FFjNQ1VOOpGYOPTHBQPnFMzrFw1BiZ80rtvFY4o/rFYWYZSS Rp4aG4hIpNfPqwFEZPK8dedp6rY0cNRJOBwl/xr1kYwW5+srY1nMYnRvTmMwXTI3 q0Y5T4k83+CnHGF6+M3l9TnBCFOA2HqR97sIOStUJQFEQCdTB/Ok3EP8VMbFGMJm KDekCwSrI0IJpIBQNlPAHmpuar4OLF87vT+dx2GkDTxAqxp7GH9C9uAAWKJgEy6f BYdvgL0SuPPRps076OvGv7TS3tvvwKYVt/dX+e4FqWhr2qQe2sRNvW+gjInezoAi ttWYjfE8xBZUvzmYNaHIo40AUAyGIkZUCxXoWqvjdj/T2BDnhisGxE+tvHuWT8NR zsMKbWU5wHd+UFXYkEMZF/YOtRa634UyMhKCAYJHFFEMJmOOf/kwiOgbKkAQz9pK WLa1emvYsL9/5QPZdbLbFc0bEiwtetGxFuOoGvlABAlC+JaBBp+RBnJ7viVrAoxy vHtdomRlKTPPggJmDxn1JcP5tCVgbSj7Ay6g/Nl

I'm on Manjaro

Of course, I'm not here to tell you how to use your computer, and it's
great that you're using Linux, but I'd suggest that you look into
installing Arch Linux proper.

Arch Linux isn't as difficult as people make it out to be (I'd argue
that anyone who's had to deal with the Calamares installer has seen
worse), and it's hugely rewarding as it gives you a fundamental overview
of how your system operates and what makes it tick, since you need to
install it yourself manually.

Plus, Manjaro holds back packages by about a month or so, sometimes
more, which breaks AUR packages, which are designed around Arch Linux's packages, which are newer. On top of this, the Manjaro team just can't
be trusted with basic things like not having their SSL certs expire on
their website (this has happened half a dozen times in the past, which
is embarassing, given that things like certbot make installing a
certificate the easiest thing in the world).

Again, I'm not some power hungry elitist Arch Linux shill or whatever,
it's your computer, use it how you want, these are just my suggestions.
Don't say I didn't warn you though :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/05/2024 10:58, Peter J. Holzer wrote:

On 2024-05-20 00:26:03 +0200, Roel Schroeven via Python-list wrote:

Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08:

Modern debian (ubuntu) and fedora block users installing using pip.

Even if you're telling it to install in ~/.local? I could see not allowing >>> to run it as root.

I assumed pip install --user would work, but no. I tried it (on Debian 12
(bookworm)):

$ pip install --user docopt
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv. >>>     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application, >>>     it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python
installation or OS distribution provider. You can override this, at the
risk of breaking your Python installation or OS, by passing
--break-system-packages.
hint: See PEP 668 for the detailed specification.

Exactly the same output for sudo pip install.

This message (quoted in all its glory) is too long to be useful. The important bit is at the end:

You can override this, at the risk of breaking your Python
installation or OS, by passing --break-system-packages.

(I admit I didn't see this the first time I got this message)

python3 -m pip install --user --break-system-packages <packagename>
does indeed install into ~/.local/lib/python3.XX/site-packages.

This inconvenient, but otoh I have accidentally installed packages into ~/.local in the past, so maybe it's good to make that more explicit.

hp

Perhaps an alias like so:

$ alias 'pip install'='pip install --user --break-system-packages'

Would work here? Someone please advise if that is a good idea.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)