On Mon, May 1, 2017 at 9:14 AM, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote: > On 1 May 2017 at 22:47, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: >> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote: >>> If the intended benefit of this change remains unclear, it may help to >>> focus on a specific concrete case, which would be that the following >>> operations should be completely indistinguishable at the system level >>> from not having done anything at all (except in the sudo logs): >>> >>> $ sudo pip3 install contextlib2 >>> $ sudo pip3 uninstall contextlib2 >> >> And this successfully ignores *all* the dependencies which contextlib2 >> may add at installation time. > > There's a reason I chose contextlib2 as my example rather than > something more complex like ansible - I'm the maintainer of > contextlib2, and I know it doesn't have any runtime dependencies (and > likely never will, since it's a stdlib module backport). Heh: it seems as if you are cheating somewhat by choosing one of the easiest components. I'm concerned that casual use of a new "pip3 install" localized utility will replicate the problems I described fairly quickly, and in ways that someone not as experienced with dependency violations will have difficulty cleaning up. I'm particularly thinking of "awscli" and the various Sphinx version dependencies of its dependency tree. > Given the proposal at hand though, writing a > `remove-pip-installed-modules` cleaner utility becomes a lot simpler > that it is today, since it just needs to clear out any Python packages > it finds in /usr/local (based on the Python level installation > records), rather than needing to interact with the RPM database, > figure out which system packages may have potentially been corrupted > and reinstall them. That makes sense, at least to me. I continue to urge you to keep it *out* of the default compiled in equivalents of PYTHONPATH. Perhaps there needs to be something like a "pip3.local", to activate such such modules in a better segregated space? One that attempts to set "bind > If the proposal is adjusted to also affect other installation > directories (like the one for scripts), it will also have the > significant benefit that any pip installed binaries will go into > `/usr/local/bin`, so they'll appear on the default path for all > regular users, but *won't* appear on the default path for "root". I do see your point. I remain concerned about system utilities like "rpm", which could wind up behaving rather differently for non-root users and for root users due to using different sets of modules by default for non-root users. And as desirable as enforcing careful "bin" directory management, I think it would require enforcing an RPM style packaging wrapper to prevent Python module installers from ignoring common "pip --install" directives, and installing in arbitrary hardcoded locations. I do remember encountering a few such modules in the last few years, I don't know if the Pytnon developer community has gotten better about that. I do hope so. The idea of providing localized segregation of pip installations is not unreasonable. I just don't think you can make it work safely by integrating it into "sudo pip3 install". Would it be simpler to provide a lightweight wrapper, a "pip3.local" script to set these alternative locations? Maybe even better, replace "/usr/bin/pip3" with the wrapper, and set the original raw "pip3" aside as "/usr/bin/pip3.bin" for operation inside the wrapper? This is an old and fairly stable stunt, used for "/usr/bin/mock" and "/usr/bin/consolehelp" to segregate the ordinarey non-root user binary from the more complex, compiled tool. > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
