On 4/19/2025 4:56 AM, Peter J. Holzer via Python-list wrote:
On 2025-04-18 13:08:36 -0400, Thomas Passin via Python-list wrote:
On 4/18/2025 11:38 AM, Peter J. Holzer via Python-list wrote:
On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote:
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".
It's not the application that looks into .local, it's Python. If you say
that a system-installed Python shouldn't look into ~/.local, then you've
just disabled that mechanism completely. If not then Python would
somehow have to distinguish between system-installed and user-installed
scripts. This isn't as easy as checking whether the path starts with
/usr/bin or whether it belongs to root. Tying into the system's package
manager doesn't look appealing to me (not to mention that it might be
unacceptably slow).
Let's try a specific example. Let's say that PyQt6 v6.8.3 is installed in
the system site directory. The OS uses PyQt6 for some system purposes. Now
the user comes along and forces an install of PyQt6 v6.9.0 in the user site
directory. 6.9.0 has a bug that would crash one of the system's application
but not the user's programs. (This is not a far-fetched scenario).
Agreed. Also since PyQt6 is a GUI framework, I'm going to assume that
those applications are supposed to be invoked by the user on their
desktop, not by a cronjob controlled by the system.
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.
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.
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.
In what scenario is a system application going to load a wrong version of a
dependency from a user's site location?
When the user sets PYTHONPATH and then accidentally invokes the
system-supplied application without resetting it first.
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, I agree and I wasn't thinking locally enough.
--
https://mail.python.org/mailman/listinfo/python-list
