Repository navigation
Expose interface to locate a physical .dist-info / .egg-info directory by distribution name #111
Description
In GitLab by @uranusjr on Feb 17, 2020, 20:29
#23 discussed whether it’d be possible to make the distribution’s _path attribute public. While I understand the rational behind not exposing it, IMO there are cases when a tool wants to find a distribution on disk. One example would be project tools wanting to perform a “clean” operation that cleans up previously-built package metadata.
Under those circumstances, the need is not to find a Distribution, and then locate it on disk (this does not make sense), but to find a dist/egg-info directory on disk (and then turn it into a Distributon; this is already possible with #90). One way to do that would be to add an interface to do something like
def locate_dist_dir(name):
for path in MetadataPathFinder._search_paths(sys.path):
if Distribution.at(path).metadata['Name'] == name:
yield path
Activity
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Mar 9, 2020, 22:34
Yes, I'd like to expose this information. The real trick is describing for other loaders what to present (if anything) for this property.
jaraco commentedon Oct 22, 2020
In GitLab by @blueyed on Mar 17, 2020, 12:42
Note that using
locate()on files is public API already, and might be usable for @uranusjr ?I also wanted to mention that with https://gitlab.com/python-devs/importlib_metadata/-/merge_requests/114 I've added a new
_locate_path, which gets adjusted for src-based egg-info distributions.I.e. I've thought that
_pathis good to point to the egg-info still, while it has extra information then about how to locate files (used bylocate()then).jaraco commentedon Oct 22, 2020
In GitLab by @uranusjr on Mar 28, 2020, 14:24
@blueyed Not sure I get what you mean, the distribution itself is not included in the list returned by
file, which is the only API I am aware of that returnsPackagePath.jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Jun 14, 2020, 16:25
@uranusjr What would you expect
locate_dist_dirto return for a dist that's persisted in an abstract store not on the file system (think SQL database)?jaraco commentedon Oct 22, 2020
In GitLab by @uranusjr on Jun 14, 2020, 21:27
Either return
Noneor raise something likeFileNotFoundError, since that is not a.dist-infodirectory.jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 23, 2020, 15:53
I'm afraid I still don't understand the distinction between these two options.
I think what you want here is something like:
Perhaps
Distributioncould get aget_local_dir()implementing that last line, such that one could:(uses one)
WDYT?
jaraco commentedon Oct 22, 2020
In GitLab by @uranusjr on Sep 23, 2020, 16:34
The impression I got from from !23 was that exposing
_pathwas considered not a good idea since not allDistributionhas a path, so my proposal was to avoid involvingDistributionclasses at all when locating the metadata directory, and provide a way turn that path into aDistributionobject afterwards. Theisinstance()andgetattr()introspection just feels wrong.A
get_local_dir()method would make sense as well, though. I would be perfectly happy if that’s the interface we go with.jaraco commentedon Jan 10, 2021
Looking at this again, I'm pretty sure
_search_pathsalready does what you need:I think we have two options.
_search_pathsfor select uses.I think I'll go for option 1 for now, for pip's purposes, until something more is needed.
jaraco commentedon Jun 8, 2023
I can see that pip never used the
_search_pathsmethod.I'm removing the protection I added for it.
Remove test_search_dist_dirs as it was never used. Ref #111.
pypi-importlib_metadata: Autospec creation for update from version 6.…