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
signature.asc
Description: PGP signature