Skip to content
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

make the Distribtion._path attribute public? #23

Closed
jaraco opened this issue Oct 22, 2020 · 7 comments
Closed

make the Distribtion._path attribute public? #23

jaraco opened this issue Oct 22, 2020 · 7 comments

Comments

@jaraco
Copy link
Member

jaraco commented Oct 22, 2020

In GitLab by @anthrotype on Nov 12, 2018, 11:39

It would be nice to be able to get the dist-info or egg-info metadata directory path for a given python package name.

For example, py2app would need to know where this metadata is on the filesystem in order to copy it inside the generated .app bundle

https://bitbucket.org/ronaldoussoren/py2app/issues/256/fs-module-not-fully-working-from-app

Currently one could do that with importlib_metadata via the Distribution._path attribute, however the leading underscore suggests that that is not part of the api.

Could/should it be made public (read-only perhaps)?

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @anthrotype on Nov 12, 2018, 11:39

changed the description

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @jaraco on Nov 21, 2018, 16:26

The problem with making that attribute public is that it's only implemented on the PathDistribution class - it doesn't have any meaning if the installed package is, for example, an importable wheel (WheelDistribution class).

I think what you're really seeking is to have a way to enumerate and read all metadata files (so they can be saved into another format). Since there's already read support (importlib_metadata.read_binary), really you just need a way to enumerate the metadata files.

I'm a little worried about this approach because of how it will be exposing implementation details of that particular metadata format (which files/structure). I'm almost tempted to say that py2app should be using the high-level interfaces to specifically support certain metadata... so invoke .metadata() and .entry_points and maybe other functionality in the future... and then store that in a known supported format (perhaps .dist-info or perhaps a custom format) in the py2app bundle.

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @anthrotype on Nov 21, 2018, 18:32

thanks, makes sense.
I gather it isn't currently possible to enumerate all metadata files?

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @jaraco on Nov 21, 2018, 19:29

Not precisely. There is an open MR !24 to allow enumeration of all files in the distribution, which would include metadata files, but doesn't designate which are metadata and which are regular files.

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @warsaw on Dec 3, 2018, 19:27

I'm going to agree with @jaraco on this. Let's close this as "won't fix" and work on the file enumeration API.

@jaraco given your last comment, I guess there's no reliable way to know whether a file is metadata or not, right?

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @warsaw on Dec 3, 2018, 19:27

closed

@jaraco
Copy link
Member Author

jaraco commented Oct 22, 2020

In GitLab by @jaraco on Dec 4, 2018, 22:59

there's no reliable way to know whether a file is metadata or not, right?

Right. Perhaps that's something the packaging tools could express. For a given Distribution, what is the metadata metadata, the type (egg-info/dist-info) and metadata version and its pertinent files.

I'd probably want to explore the py2app use-case in a bit more detail or identify another use-case that demands this functionality before I'd feel good recommending it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant