From Newsgroup: comp.lang.python

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!
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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. 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!

The other thing to consider is whether it will be a standalone app or
a GUI component. If the latter do you want to expose your own API or
clone the manufacturers? Or both?!
Or you could make it an object that can be used both in GUIs and in
"robotic" or "batch" mode. So many options.

Most of the specs are available online and there must be dozens of
terminal emulators around written in C so you should have plenty
of sample code to study. Good luck!
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-14, Alan Gauld via Python-list <[email protected]> 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.

You also need to decide if you're going to support real serial ports
or just ptys.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-14, Alan Gauld via Python-list <[email protected]> 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.

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.

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...





--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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).
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

The topic was to re-invent the wheel yet again and create a terminal
emulator.

I hesitate to say this but one approach is to consider the curses module as described by our very own Alan Gauld in a book:

https://www.amazon.com/Programming-curses-Python-Alan-Gauld-ebook/dp/B091B85 B77

The topic is how to make a terminal emulator and as Alan mentions, each kind
of terminal may accept various kinds of escape sequences. There are files available the are normally used by curses to get a description of sorts of
the capabilities and details of a terminal like a VT100 that curses can use
to decide what stream of bytes to send to update a screen.

You might be able to use something similar, or better, to see what your terminal emulator should emulate.

And, it may even be possible for you to emulate lots of terminals with the
same basic code.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=[email protected]> On Behalf Of Alan Gauld via Python-list
Sent: Tuesday, May 14, 2024 3:07 PM
To: Gordinator <[email protected]>; [email protected]
Subject: Re: Terminal Emulator

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. 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!

The other thing to consider is whether it will be a standalone app or
a GUI component. If the latter do you want to expose your own API or
clone the manufacturers? Or both?!
Or you could make it an object that can be used both in GUIs and in
"robotic" or "batch" mode. So many options.

Most of the specs are available online and there must be dozens of
terminal emulators around written in C so you should have plenty
of sample code to study. Good luck!
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 14May2024 18:44, Gordinator <[email protected]> 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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

Gordinator <[email protected]> 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!
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python


--jrt2la52cu3cb7wf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

On 2024-05-14, Alan Gauld via Python-list <[email protected]> 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.

=20
If you want to make life easier, make it a superset of a terminal that already exists in the terminfo database.
=20
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!

=20
"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

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

--jrt2la52cu3cb7wf
Content-Type: application/pgp-signature; name="signature.asc"

-----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+bIGnfVeqlvrcDmsEywVqrk9kAtqrYR3M8OiE=
=4loP
-----END PGP SIGNATURE-----

--jrt2la52cu3cb7wf--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python


--s4wtimvzro3m2ipr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
=20
If you have any advice, please do let me know!

=20
=20
Not sure, what you mean with:
=20

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 a=

nd

*has* a text widget as its visible core. If you want to write something l=

ike

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

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

--s4wtimvzro3m2ipr
Content-Type: application/pgp-signature; name="signature.asc"

-----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+GX9UFBZ6192uIOImoB3C2Qo5c=
=9/Vr
-----END PGP SIGNATURE-----

--s4wtimvzro3m2ipr--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python


--yfbpku6vrxn4lior
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 Li=

nux

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

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

--yfbpku6vrxn4lior
Content-Type: application/pgp-signature; name="signature.asc"

-----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+8KTz+n3oExKi5o=
=ilcc
-----END PGP SIGNATURE-----

--yfbpku6vrxn4lior--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-18, Peter J. Holzer via Python-list <[email protected]> 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, and I've
yet to use a venv...

--
Grant


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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

On 2024-05-18, Peter J. Holzer via Python-list <[email protected]> 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...



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-18, Mats Wichmann via Python-list <[email protected]> wrote:

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.

For a few years I needed both 2.x and 3.x installed, but my distro
(Gentoo) handled that fine (I think most others do also). Gentoo also
allows multiple minor versions to be installed (currently I have 3.11
and 3.12 on this machine).

But, since Gentoo is a source-based meta-distro, when I install a
Python package, the package manager knows how to install it for all
installed Python versions that are supported by the package.

I can't think of why I would need a venv unless I needed to test
something with a Python version that isn't available for Gentoo. That
said, there are currently 7 versions available (2.7.18, 3.8.19,
3.9.19, 3.10.14, 3.11.9, 3.12.3, 3.13.0).

3.13 isn't marked stable yet in the Gentoo package database, and I
apparently have some Python app/package installed that doesn't yet
support 3.12, so I've currently got both 3.12 and 3.11.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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

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

Not so much down on them, they are just one extra step that's
mostly not needed(in my use case)

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

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

Well, I've been using Python since 1998 on Linux, Windows
and MacOS and have yet to find a use for a venv. I've
played with them when they first came out but haven't
actually found a scenario where I've thought "I need
a venv for that!"

But then I'm a sole user, I have 3 or 4 projects going
but only me working on them. I only have 2 Python versions
at any time and the OS handles that just fine without
any venvs.

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.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-19, Alan Gauld via Python-list <[email protected]> wrote:

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.

Same here. I occasonlly use pip to install something that isn't
packaged for Gentoo, but it doesn't seem to cause problems — let alone nightmares. I also occasionally package something myself.

--
Grant




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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...




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-19 at 18:13:23 +0000,
Gilmeh Serda via Python-list <[email protected]> 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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-19 at 18:13:23 +0000,
Gilmeh Serda via Python-list <[email protected]> wrote:

Was there a reason they chose the name Pip?

Package Installer for Python

https://pip.pypa.io/en/stable/index.html
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <[email protected]> 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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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 <[email protected]> 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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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).
Skip
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-19, Gilmeh Serda via Python-list <[email protected]> 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?

I always assumed it was in honor of the PIP (Peripheral Interchange
Program?) utility that was used to copy files around on CP/M and DEC's
PDP-11 OSes.

--
Grant



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

On 2024-05-19, Barry via Python-list <[email protected]> wrote:

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <[email protected]> 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?

--
Grant

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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

On 2024-05-19, Barry via Python-list <[email protected]> wrote:

On 18 May 2024, at 16:27, Peter J. Holzer via Python-list <[email protected]> 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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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 <[email protected]> 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.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python


--qp3b4lp4gnlnrmel
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

=20
Even if you're telling it to install in ~/.local? I could see not allow=

ing

to run it as root.

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

$ pip install --user docopt
error: externally-managed-environment
=20
=C3=97 This environment is externally managed
=E2=95=B0=E2=94=80> To install Python packages system-wide, try apt ins=

tall

=C2=A0=C2=A0=C2=A0 python3-xyz, where xyz is the package you are trying=

to

=C2=A0=C2=A0=C2=A0 install.
=20
=C2=A0=C2=A0=C2=A0 If you wish to install a non-Debian-packaged Python =

package,

=C2=A0=C2=A0=C2=A0 create a virtual environment using python3 -m venv p=

ath/to/venv.

=C2=A0=C2=A0=C2=A0 Then use path/to/venv/bin/python and path/to/venv/bi=

n/pip. Make

=C2=A0=C2=A0=C2=A0 sure you have python3-full installed.
=20
=C2=A0=C2=A0=C2=A0 If you wish to install a non-Debian packaged Python =

application,

=C2=A0=C2=A0=C2=A0 it may be easiest to use pipx install xyz, which wil=

l manage a

=C2=A0=C2=A0=C2=A0 virtual environment for you. Make sure you have pipx=

installed.

=20
=C2=A0=C2=A0=C2=A0 See /usr/share/doc/python3.11/README.venv for more i=

nformation.

=20
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.

=20
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

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

--qp3b4lp4gnlnrmel
Content-Type: application/pgp-signature; name="signature.asc"

-----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/Nle9lbfsNnYYt0=
=VaMG
-----END PGP SIGNATURE-----

--qp3b4lp4gnlnrmel--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.python

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 :)
--- Synchronet 3.20a-Linux NewsLink 1.114