🌐 Mailman 3 April 2025 - Python-list - python.org

Module urljoin does not appear to work with scheme Gemini
by Schimon Jehudah April 24, 2025

April 24, 2025

Good day. Yesterday, I have added support for a new syndication format, Gemini feed. Yet, it appears that module urljoin fails at its task, even though module urlsplit correctly handles Gemini. Python 3.13.3 >>> from urllib.parse import urljoin >>> urljoin('gopher://gopher.floodgap.com:70/1/overbite', '../one-level-up') 'gopher://gopher.floodgap.com:70/one-level-up' >>> urljoin('gopher://gopher.floodgap.com:70/1/overbite', 'same-level') 'gopher://gopher.floodgap.com:70/1/same-level' >>> urljoin('gemini://woodpeckersnest.space/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi', '../one-level-up') '../one-level-up' >>> urljoin('gemini://woodpeckersnest.space/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi', 'same-level') 'same-level' >>> from urllib.parse import urlsplit >>> urlsplit('gopher://gopher.floodgap.com:70/1/overbite') SplitResult(scheme='gopher', netloc='gopher.floodgap.com:70', path='/1/overbite', query='', fragment='') >>> urlsplit('gemini://woodpeckersnest.space/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi') SplitResult(scheme='gemini', netloc='woodpeckersnest.space', path='/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi', query='', fragment='') >>> https://git.xmpp-it.net/sch/Slixfeed/src/branch/master/slixfeed/parser/gmi.… Is this a problem with the module urljoin? To whom should reports about such concern be conveyed? Please advise. Kind regards, Schimon

3 4

Re: Pip installs to unexpected place
by rbowman April 20, 2025

April 20, 2025

On Sat, 19 Apr 2025 15:56:16 -0400, Thomas Passin wrote: > My problem with venvs, especially if I have more than one, is that I > eventually forget what they were for and what is different about each > one. If there's only one and it's used for all non-system work, that's > OK but beyond that and they tend to suffer knowledge rot. My Python directory has apple/ create/ fastapi/ lunar/ numerical/ pyside6/ weather/ comics/ django/ folium/ ml/ sqlite/ coursera/ impractical/ nn/ pyqt/ torch/ Not all like sqlite are venvs since no additional modules are needed. Even if I'm a little hazy about 'apple' after a while a quick look at the Python file shows 'https://itunes.apple.com/search' and I remember it is to pull down artist/track info from the itunes database. I also try to remember to run 'pythom -m pip freeze > requirements.txt' after I get everything set up. That way if a OS update installs a new version of Python something like python3 -m venv folium cd folium . bin/activate python -m pip install -r requirements.txt will refresh the venv and install the appropriate packages for the new Python version. That's faster than looking at lib/python3.10/site-packages or whatever the previous version was and adding the dependencies or trying to run the py file and getting Traceback (most recent call last): File "/home/rbowman/work/python/impractical/benford.py", line 5, in <module> import matplotlib.pyplot as plt ModuleNotFoundError: No module named 'matplotlib'

1 0

Re: Pip installs to unexpected place
by Greg Ewing April 19, 2025

April 19, 2025

On 18/04/25 9:41 am, Mats Wichmann wrote: > There's just not a really great answer to this. Seems to me a system-installed application shouldn't be looking in the user's .local packages in the first place. That should only be for things the user has installed "for this user". -- Greg

4 6

Re: Pip installs to unexpected place
by songbird April 19, 2025

April 19, 2025

Peter J. Holzer wrote: > On 2025-04-18 13:08:36 -0400, Thomas Passin via Python-list wrote: ... >> When the system launches its application the PYTHONPATH will start with >> system site directories; local user site directories will be on the >> PYTHONPATH but since they come later, the python will use PyQt6 v6.8.3 >> because that will come first on the path. No crash here. >> >> If the user has a program that actually does require the use of v6.9.0, he's >> going to have to make sure that the user's local site directories come first >> on the path. One way to do that is to set the PYTHONPATH to point to the >> user's location. > > This is IMHO not practical. The user would have to set PYTHONPATH for > some programs, but not for others. You can't do this with .bashrc (or > similar), the user would have to write a wrapper script for each of > their programs which depend on something in ~/.local. Possible of course > but cumbersome. currently in my .bashrc i have it set up to look for which directory the terminal is in and then runs the activate script for that environment. i like to keep my desktops/projects open with various numbers of terminals available so this way they are all ready to go when the system boots up. > I like Oscar's suggestion that Python scripts provided by the > distribution include -s in the shebang much better. > > Or - what I tend to do - simply use a virtual environment for each > script that needs a package that the system doesn't provide. But of > course that's basically "disable/don't use .local" and all those venvs > take space and need to be maintained. i like that they do not change until i specificly ask them to be changed. ... >> The only one I can think of is for the user, with the help of sudo, or >> by editing some system-enabled script, were to change the global >> PYTHONPATH. That seems a stretch. > > No, there doesn't have to be a global (in the sense that it applies to > all users) PYTHONPATH for that to happen. You just need a PYTHONPATH > that is set for all processes of that user - which the user can > certainly set without sudo (usually by editing .bashrc or maybe using > their desktop environment's settings dialog). yes, that is part of what .bashrc is for, making sure your environment variables are set how you'd like them. songbird

1 0

Pip installs to unexpected place
by Jonathan Gossage April 17, 2025

April 17, 2025

I am using *Python 3.13* in a virtual environment under *Ubuntu Linux 24.04* . The version of Python was compiled from source code and installed with make altinstall. I attempted to use *pip* to install the *Sphinx* package into the virtual environment using the command *pip install sphinx* in the virtual environment*.* I expected that *sphinx* would be installed in the *site-packages* directory in the virtual environment. Instead, it was installed into the site-packages directory in */home/jonathan/.locals/lib/python3.13/site-packages* even though I did not specify *--user* to the *pip install* command. Is this expected behavior? I wanted Sphinx to be installed in the virtual environment so that it would be accessible to all users of the virtual environment. -- Jonathan Gossage

8 14

Re: Pip installs to unexpected place
by rbowman April 16, 2025

April 16, 2025

On Tue, 15 Apr 2025 14:12:19 -0400, Thomas Passin wrote: > On Linux, at least, it's standard for pip to install into the user's > site-packages location if it's not invoked with admin privileges - even > without --user. Pip will emit a message saying so. Well, that used to be > true but nowadays Pip wants you to use the --break-system-packages flag > if you want to insist on installing into the system's Python install, > even if it's going to go into --user. I'm not sure if the restriction > will be in place given that the OP built his own Python version. Is that pip or a distro's version of pip? On Fedora I get the message about defaulting to user. On Ubuntu I get a message to use a venv or if I really want a global install to use something like 'pip install python3- black'. Ubuntu's is pip 24.2, Fedor's is 24.3.1 but neither of them show '--break-system-packages' in --help.

2 1

Re: Pip installs to unexpected place
by rbowman April 15, 2025

April 15, 2025

On Tue, 15 Apr 2025 18:43:43 +0200, Friedrich Romstedt wrote: > Many people put emphasis on that you need to *activate* a virtualenv > before using it, but no-one so far stressed the fact that you got Sphinx > installed to ~/jonathan/.local/lib/python3.13/site-packages *without > using *--user. This may depend on the OS. On Ubuntu 24.10 with python 3.12.7 I get $ pip install black 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. I do have '/home/rbowman/.local/lib/python3.10/site-packages' left over from earlier versions of Ubuntu. However on Fedora 42 with 3.13.2 Defaulting to user installation because normal site-packages is not writable.

1 0

Re: Pip installs to unexpected place
by Keith Thompson April 15, 2025

April 15, 2025

Thomas Passin <list1(a)tompassin.net> writes: [...] > To activate a venv, you have to source its activate script, which is > in the venv. First you have to mark it as executable. Then you source > it - > > source ~/venv/gf4/bin/activate [...] No, you don't have to (and probably shouldn't) mark the script as executable. Making a script executable (chmod +x) is required before *executing* it, but when you *source* a script (using "source" or "."), your current shell reads it and evaluates its content. Making the active script executable introdues the risk that you'll accidentally execute it rather than sourcing it. If you do that, it will probably set up the environment in a new shell process which then immediately terminates. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u(a)gmail.com void Void(void) { Void(); } /* The recursive call of the void */

3 3

Re: Pip installs to unexpected place
by rbowman April 14, 2025

April 14, 2025

On Mon, 14 Apr 2025 09:55:09 -0400, Thomas Passin wrote: > Pip doesn't know about the environment it runs in. It seems to me that > you didn't active the venv before you installed using pip. So nothing > would have gotten installed into the venv. So where is the venv that you > set up? I usually put them into ~/venv. For example, a venv named "gf4" > is at ~/venv/gf4. Are you sure about that? activate has VIRTUAL_ENV="/home/rbowman/work/python/weather" export VIRTUAL_ENV _OLD_VIRTUAL_PATH="$PATH" PATH="$VIRTUAL_ENV/bin:$PATH" export PATH $PATH is modified to point to the bin directory in the venv, and it includes python and pip. You can use 'python3' if you really want to since it is there also. $ which pip /home/rbowman/work/python/weather/bin/pip 'deactivate' restores $PATH. I'll agree it sounds like the venv wasn't activated.

2 1

Re: Pip installs to unexpected place
by Thomas Passin April 14, 2025

April 14, 2025

Please include the group in your response; don't just send it to me. On 4/14/2025 5:09 AM, Jonathan Gossage wrote: > The virtual environment was owned by the user running pip. It was not > owned by root. Does pip not support virtual environments that are owned > by a non-root user and have a multi-user secondary group? The actual > command was *pip install mypy flake8 sphinx*. The other packages were > also installed into the user .local tree and work properly for the user > doing the installation, but not for other members of the group that have > access to the virtual environment. Pip doesn't know about the environment it runs in. It seems to me that you didn't active the venv before you installed using pip. So nothing would have gotten installed into the venv. So where is the venv that you set up? I usually put them into ~/venv. For example, a venv named "gf4" is at ~/venv/gf4. To activate a venv, you have to source its activate script, which is in the venv. First you have to mark it as executable. Then you source it - source ~/venv/gf4/bin/activate Now when you run python (or more likely, python3), it will find the venv's directories before it will find the system's or user's. You know the activation has been successful because the prompt changes to show you. The activation applies to the terminal session in which you activated the venv. > On Sun, Apr 13, 2025 at 10:11 PM Thomas Passin <list1(a)tompassin.net > <mailto:list1@tompassin.net>> wrote: > > On 4/13/2025 7:10 PM, Jonathan Gossage via Python-list wrote: > > I am using *Python 3.13* in a virtual environment under *Ubuntu > Linux 24.04* > > . > > The version of Python was compiled from source code and installed > with make > > altinstall. I attempted to use *pip* to install the *Sphinx* > package into > > the virtual environment using the command *pip install sphinx* in the > > virtual environment*.* I expected that *sphinx* would be > installed in the > > *site-packages* directory in the virtual environment. Instead, it was > > installed into the site-packages directory in > > */home/jonathan/.locals/lib/python3.13/site-packages* even though > I did not > > specify *--user* to the *pip install* command. Is this expected > behavior? I > > wanted Sphinx to be installed in the virtual environment so that > it would > > be accessible to all users of the virtual environment. > > If you ran the command as a user, then pip would not have root > privileges and could not install into the system directory. It would > fall back to installing into the user's tree. It usually prints a > message to that effect. That's standard behavior if you don't have the > venv activated. > > If you want to install something into a virtual environment, you > have to > activate the environment before installing the something. > > A complication could occur if the system's Python version is the > same as > the one you built. You might inadvertently run the system's binary of > python 3.13 instead of your own. I'm not familiar with the make > altinstall command but I doubt that it changes the ordinary rules for > invoking python and using a venv. > > > > -- > Jonathan Gossage

1 0