Is there a tool that (1) detects import name collisions; and (2) attempts to read package metadata and package file checksums (maybe from the ZIP 'manifest')?
In order to: - troubleshoot module shadowing issues - $PATH - sys.path - `python -m site` - incomplete and overlapping uninstallations: pip install a pip install a_modified # pip uninstall a? pip install pdbpp pip uninstall a_modified ls -altr "${site-packages[*]}" strace -e trace=file python -c 'import pdb' **** When shouldn't site customizations be added to the site module? https://docs.python.org/3/library/site.html When should customizations be built into the build instead of a runtime conditional? On Sat, Feb 27, 2021, 23:12 Nick Coghlan <ncogh...@gmail.com> wrote: > On Wed, 24 Feb 2021 at 10:49, Random832 <random...@fastmail.com> wrote: > > > > I was reading a discussion thread < > https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about > various issues with the Debian packaged version of Python, and the > following statement stood out for me as shocking: > > > > Christian Heimes wrote: > > > Core dev and PyPA has spent a lot of effort in promoting venv because > we don't want users to break their operating system with sudo pip install. > > > > I don't think sudo pip install should break the operating system. And I > think if it does, that problem should be solved rather than merely advising > users against using it. And why is it, anyway, that distributions whose > package managers can't coexist with pip-installed packages don't ever seem > to get the same amount of flak for "damaging python's brand" as Debian is > getting from some of the people in the discussion thread? Why is it that > this community is resigned to recommending a workaround when distributions > decide the site-packages directory belongs to their package manager rather > than pip, instead of bringing the same amount of fiery condemnation of that > practice as we apparently have for *checks notes* splitting parts of the > stdlib into optional packages? Why demand that pip be present if we're not > going to demand that it works properly? > > The reason venv is promoted as heavily as it is is because it's the > only advice that can be given that is consistently correct regardless > of the operating system the user is running locally, whereas safely > using a system-wide Python installation varies a lot depending on > whether you're on Windows, Mac OS X, or Linux (let alone some other > platform outside the big 3 desktop clients). > > conda is also popular for the same reason: while the instructions for > installing conda in the first place are OS-dependent, once it is up > and running you can use consistent platform independent conda commands > rather than having to caveat all your documentation with > platform-specific instructions. > > Apple moved all of their dynamic language interpreter implementations > to inaccessible-by-default locations so Mac OS X users would stop > using them to run their own code. > > Alongside that, we *have* worked with the Linux distro vendors to help > make "sudo pip install" safe (e.g [1]), but that only helps if a user > is running a new enough version of a distro that has participated in > that work. > > However, while the option of running "platform native" environments > will never go away, and work will continue to make it less error > prone, the level of knowledge of your specific OS's idiosyncrasies > that it requires is almost certainly going to remain too high for it > to ever again become the default recommendation that it used to be. > > Cheers, > Nick. > > [1] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe (Note: > this change mitigated some aspects of the problem in a way similar to > what Debian does, but still doesn't solve it completely, as custom > Python builds may still make arbitrary changes) > > P.S. "But what about user site-packages?" you ask. Until relatively > recently, Debian didn't put the user's local bin directory on the > system path by default, so commands provided by user level package > installs didn't work without the user adjusting their PATH. The > CPython Windows installer also doesn't adjust PATH by default (for > good reasons). And unlike a venv, "python -m" doesn't let you ensure > that the code executed is the version installed in user site-packages > - it could be coming from a directory earlier in sys.path. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/RDLEH6DUF57UB6U4HNL2QRVAJY4KDSSJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/53QLFDWF6FOFTTQSY4ZL7NLXNWJSXVZV/ Code of Conduct: http://python.org/psf/codeofconduct/