[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python 3.4 and ensurepip (rehashed, long)



On Mar 26, 2014, at 12:15 AM, Scott Kitterman wrote:

>If I've install a package and it's upgraded (this is for the system, not for
>any kind of virtualized/isolated environment), I would find it quite
>surprising and unfortunate that it upgraded itself from an external source.

IMO, if you've apt-get installed a package, this goes in /usr/lib and no way
would pip --upgrade upgrade that.  IOW, for modules installed with apt-get,
apt-get is the only way to upgrade it.

It follows then, that if you've sudo pip installed something into /usr/local,
then pip --upgrade *can* upgrade that.

The tricky place is whether you will allow an apt-get installed module to be
sudo pip --upgraded by installing the newer externally sourced package into
/usr/local.  That would require /usr/local to come first on sys.path, which is
the case currently at least on Debian.

I do think this would require a --dont-blame-us switch analogous to
-s/$PYTHONNOUSERSITE.  We'd want to recommend adding that switch to shebang
lines for system services and scripts, much like we already do with -Es.  For
complete isolation, -I should imply this new switch too.

In fact, given that we *already* include
/usr/local/lib/pythonX.Y/dist-packages on sys.path, I think it's a deficiency
that we don't define such a switch (but we'd want to pick something that would
align with an upstream choice for this switch).

Cheers,
-Barry

Attachment: signature.asc
Description: PGP signature


Reply to: