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/
