Hooks for other loaders about importlib_metadata

[jaraco]

In GitLab by @warsaw on May 23, 2018, 21:03

Do you think it should live on the loader or on the finder? I was thinking the latter, but given that importlib.resources uses the loader, maybe that makes more sense for consistency.

We definitely need an extensibility layer a la importlib.resources because currently, the implementation is only compatible with file system distributions (i.e. not zips). See this issue for some related discussion.

I think we should do this before the first release.

[jaraco]

In GitLab by @jaraco on Jul 22, 2018, 18:57

Do you think it should live on the loader or on the finder?

I hadn't thought about it much before today. And I'm not sure even after thinking about it for over an hour that I have more insight than I did before. I think the crux of the question is - does a finder have enough context to determine if the metadata is present? It seems to me since a PathFinder is relevant for both SourceFileLoader and ZipFileLoader, but package metadata is going to need to be loaded differently based on those two loaders. That leads me to think that it's the loader that will be the designator for how metadata is loaded.

Plus, that's how it was done in pkg_resources.

@warsaw, What is it about finders that leads you to think they would be the key designator?

[jaraco]

In GitLab by @jaraco on Jul 22, 2018, 19:25

The more I think about it, the less I think the finder/loader mechanism is the right approach. The resolution of the Distribution needs to happen at a layer even before finders. Just like how pkg_resources would allow for get_provider(moduleOrReq) (ref), this package needs to present a way to solicit new distribution finders, such that when a package is "installed" through something like pyinstaller, it doesn't matter how the module was installed/found/loaded - what matters is how to load metadata for that module's Distribution (e.g. it doesn't matter how pkg_resources was loaded but where setuptools==40.0.0 has metadata), which is independent of how the modules are found/loaded.

pkg_resources managed this lookup with the working_set and the require logic (which would traverse the system for installed Distributions).

On a related note, I think what this implies is that the Distribution.from_name is the one (and only) place that another installer would need to register its hook.

Hmm. Okay, now I think I see why the finder might be the right place... because it's visible and searchable before any finding or loading is done.

[jaraco]

In GitLab by @jaraco on Sep 3, 2018, 22:10

mentioned in commit 8b53276

[jaraco]

In GitLab by @jaraco on Sep 3, 2018, 22:10

mentioned in commit 74e40e2

[jaraco]

In GitLab by @jaraco on Sep 3, 2018, 22:10

mentioned in commit ad4636b

[jaraco]

In GitLab by @jaraco on Sep 3, 2018, 22:19

mentioned in merge request !2

[jaraco]

In GitLab by @warsaw on Sep 4, 2018, 21:37

mentioned in merge request !3

[jaraco]

In GitLab by @jaraco on Sep 8, 2018, 02:55

closed via merge request !2

[jaraco]

In GitLab by @jaraco on Sep 8, 2018, 02:55

closed via commit ad4636b

[jaraco]

In GitLab by @jaraco on Sep 8, 2018, 02:55

closed via commit 8b53276

[jaraco]

In GitLab by @jaraco on Sep 8, 2018, 02:55

mentioned in commit 08f79d7