Article <mailman.24.1745052976.3008.python-list@python.org>

Deutsch English Français Italiano
<mailman.24.1745052976.3008.python-list@python.org>

View for Bookmarking (what is this?)
Look up another Usenet article
Path: ...!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Peter J. Holzer" <hjp-python@hjp.at>
Newsgroups: comp.lang.python
Subject: Re: Pip installs to unexpected place
Date: Sat, 19 Apr 2025 10:56:14 +0200
Lines: 111
Message-ID: <mailman.24.1745052976.3008.python-list@python.org>
References: <4ZcdYR5WnWznV1q@mail.python.org>
 <cc1c6cf5-f8b9-4528-b6b0-110499b88162@wichmann.us>
 <4Zd3YM00SYznVKQ@mail.python.org>
 <CAJQBtgmfgC5aQy_7RXwHDbsxaf1UWYY0=FNsgPPR2UzzuKfTTA@mail.gmail.com>
 <4ZdrJv0v0LznV1q@mail.python.org>
 <6d1ac10c-80c0-484b-a7e7-e1966cea1b5d@wichmann.us>
 <mailman.19.1744926071.3008.python-list@python.org>
 <m6dnueFg8f0U1@mid.individual.net>
 <20250418153848.w2hmxpegl3uwii3w@hjp.at>
 <e1cce2f7-e59b-42bb-95ee-602f241f545b@tompassin.net>
 <20250419085614.vbgzh7h7hggyhzsd@hjp.at>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="vp5o7ne6zbzmsmpv"
Cancel-Lock: sha1:AO5jYLu0mxMa7gtNy6jMlaBw1m4= sha256:3bNHs7TDXuB4wMVzRtXwfBt7y++04Uit2UHb3W25qG0=
Mail-Followup-To: python-list@python.org
Content-Disposition: inline
In-Reply-To: <e1cce2f7-e59b-42bb-95ee-602f241f545b@tompassin.net>
Precedence: list
Bytes: 10073


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

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.
> > >=20
> > > 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 th=
ings
> > > the user has installed "for this user".
> >=20
> > 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).
>=20
> 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 si=
te
> directory. 6.9.0 has a bug that would crash one of the system's applicati=
on
> 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.
>=20
> If the user has a program that actually does require the use of v6.9.0, h=
e's
> going to have to make sure that the user's local site directories come fi=
rst
> 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.

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

        hjp

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

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

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

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmgDZSgACgkQ8g5IURL+
KF2Fgw/+JSjASdQ79OXceKZHRToWr38cbCb9O5Q74xaoIjbOjrBK/Rgz3OFsSFxU
NmwxxXvRiPkOa1KnvawDXmj/iedEqx1hIFJ+Nc66t7lyrWAtu7MSW/gmxXawGbL+
Y40/jMN6US0Ra9ZeYt1Jv/nU7qqgdT/p3mtDnQXlG3LLOZZEHhu//pS09tUHD7a/
y2B88/QzCe2WqnNEGnId+LUIzocEGTGKKWss7MVguKAw86ZxqA6tdv5W7GNTkHfb
l77rJcaiJx/tAH29lbheo34WfHW3BpdACxBwgqLQJZmqqrLb4rY36mh540r2yGpU
bVfdTWbRvFUkJVcRdvdDpKagShSLA5a2nxU9D8BVlSz8rbAOofHzKkDN+ZiC3OWb
f6Xgz/eBVuxWDENOTobJOCiI8pCiPay7qlT9v9UVmKYotY7Rj3PysSUfyvhIPqSf
+rarT1puLYAnorj+S54KkVBFKsU21wOMKGqg0YONn5rXRzbo1H6HIGcgwdz/7uNn
hYZp5y0G0L+lIacueemMXQrhvfcu9OSSMqzakLMfzT1IAY5BtiDD7k07jD0ZFIAy
cFJPuq3mLYVZi40xOlkuC5kPb72cVOMgIN1BXgZWhMqVDrSClqnXa2ASZu4WxWpr
========== REMAINDER OF ARTICLE TRUNCATED ==========