-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No package inspection routines outside pkg_resources #317
Comments
(initial reactions based on reading this and thinking about this for a bit before dinner) tl;dr: (1) let's avoid (2) let's do it (3) let's not do it
Is there any reason to avoid making
This sounds like a good idea to me and I'm on board for adding something like this. We'd definitely want to spend some time figuring out a good design for this functionality; much like we did for
I strongly prefer that With my With my |
I’m wondering, what exactly should go into (say) from importlib.metadata import distribution as get_distribution
from packaging.specifiers import SpecifierSet
from packaging.version import parse as parse_version
def pkg_installed(name: str, spec: SpecifierSet):
if (dist := get_distribution(name)) is None:
return False
return parse_version(dist.version) in spec (Note: there is a functional difference between this and (Minor grumble: I really wish I would find it hard to justify making |
Consider also this use-case, where retrieving the list of dependencies of a given package is far from trivial. I'd really like to avoid recommending that users copy/paste whole segments of code, especially when those segments have multiple imports. |
O markers and extras, the bane of us all. Thanks, that makes perfect sense. (Minor grumble 2: The whole things seem to be complicated a lot by all the I still wonder whether it is possible to avoid coupling
I would definitely be +1 to include such logic as |
Another area of interaction is between |
In pypa/setuptools#2116, a user has this case:
|
Regarding the stdlib-inclusion question, I think packaging would make a lot of sense as something for "ensurepip" to explicitly install as a public guarantee. |
If we're going down that route, maybe the |
Another use-case requested in python/importlib_metadata#450:
|
One of the goals of
importlib.resources
and.metadata
was to replace Setuptools'pkg_resources
. There's still a big gap thatpkg_resources
supplies that these packages do not, and that's inspection of the environment for the presence of a package. In particular, the user wants to know:requests>=2
), is that package installed and if so, what package is it?For example,
pip-run
relies on pkg_resources to determine if a package is installed at a given spec.When trying to re-implement these behaviors using
importlib_metadata
, I find it's clumsy and complicated, because it requires substantial implementation by the client but also because it usually depends on the third-party packaging project, which because it isn't available in the stdlib, means it's not possible to have this behavior in the stdlib. The objects and models inpackaging.version
andpackaging.specifiers
andpackaging.requirements
are essential to performing some of the desired operations without setuptools.Put simply, it's difficult to find a home for the functionality which necessarily overlaps the functionality in packaging and metadata.
What's to be done about this?
I've been mulling this over and every time I think about it, I come to the same conclusion (proposal):
.inspector
or.environments
.That third aspect is certainly debatable, and maybe the conclusion is that this behavior remains third-party indefinitely.
@warsaw Do you have any instinct on this matter? @dstufft I know you have had some thoughts on this matter; what would you recommend?
Is there a promising alternative to this issue that I haven't considered?
The text was updated successfully, but these errors were encountered: