There is no mechanism provided for build requirements to have extras.
It should be acceptable to enforce that any "optional" packages
that are supposed to be conditionally installed based on the presence of
an extra should not be installed in a build environment.
This fallback is only triggered if the project has a `setup.py` file.
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com>
Co-authored-by: Pradyun Gedam <pradyunsg@gmail.com>
This would make it easier to diagnose what an issue might be, related to
this logic, since the things that affect whether the message is printed,
are now available in the debugging logs.
This style makes the upgrade prompt less of blurb of yellow text, making
it easier to read while clarifying the presentation style to make it
easier to figure out what the user is supposed to run.
Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com>
- Move the lookup within `selfcheck/*.json` files into a method on
`SelfCheckState`.
- Factor out `PackageFinder` interaction into a separate function.
- Rename variables to more clearly reflect what they're for.
Co-Authored-By: Pradyun Gedam <pradyunsg@gmail.com>
Instead of a flag, make the option take an argument like this:
--root-user-action=ignore
This allows us to add more alternatives in the future, for example to
emit a hard error when a root user is detected.
Also re-label the news fragment to point to the issue instead of the PR
that introduced the option.
A distutils installation is always "flat" (not in e.g. egg form), so
if this distribution's info location is NOT a pathlib.Path (but e.g.
zipfile.Path), it can never contain any distutils scripts.
This replaces importlib.metadata's parser and allows us to "properly"
normalize extras as we need. It is not wrong for importlib.metadata to
not normalize extras --- if extra normalization is standardized
properly, packaging.markers should instead implement 'evaluate()' to
properly normalize on comparison, instead of just doing a naive string
equality check. Unfortunately, no-one has made a concrete effort to make
that happen yet, so pip needs to do what it needs to do to keep things
working.
This matches pkg_resources's behavior. There are various places in the
code base that assumes only one entry is returned for a package name,
and not doing that would potentially cause a distribution in lower
precedence path to override a higher precedence one, if the caller is
not careful.
Eventually we probably want to make it possible to see lower precedence
installations as well (it's useful), but this is not the time.
Pradyun Gedam
Tzu-ping Chung
Pradyun Gedam
Stéphane Bidoul
wim glenn
Paul Moore
Tomáš Hrnčiar
Pradyun Gedam
Frost Ming