`importlib_metadata.entry_points` api is surprising

[jaraco]

In GitLab by @asottile on Feb 13, 2019, 03:40

what I expected:

entry_points('pytest') => return me a mapping of pytest's entry points

reality:

entry_points('pytest') => ignore the passed in name argument (never referenced in function) and return all entrypoints for all distributions

[jaraco]

In GitLab by @jaraco on Feb 14, 2019, 15:30

You're right, entry_points shouldn't accept a parameter it doesn't use.

I think I intended that parameter to only return entry points of a given group, e.g. entry_points('console_scripts'), but then I realized that one could nearly as easily do entry_points()['console_scripts'], so the latter is the recommended usage.

[jaraco]

In GitLab by @jaraco on Feb 14, 2019, 15:31

It's amazing to me that with all the annoying nitpicks the linters throw at me on a daily basis that it wouldn't have caught something as obvious as an unused parameter.

[jaraco]

In GitLab by @jaraco on Feb 14, 2019, 15:34

mentioned in commit bcfb9f5

[jaraco]

In GitLab by @asottile on Feb 14, 2019, 15:34

heh, it happens. I assume the api I want for "pytest's entry points" is distribution('pytest').entry_points ?

[jaraco]

In GitLab by @jaraco on Feb 14, 2019, 15:35

mentioned in merge request !39

[jaraco]

In GitLab by @jaraco on Feb 14, 2019, 18:16

Is there a use-case where you want all the entry points for a given package? My assumption was that the prime if not sole case for querying entry points was by group across all packages.

[jaraco]

In GitLab by @asottile on Feb 14, 2019, 20:48

I don't see it being a super common one, but I did need it for pytest:

https://github.com/asottile/pytest/commit/80e7a5acda5e3ed8af4ac0b03bc413a84e535061#diff-5d8f198ea47ec74b77274fb69b15cf4fR10

[jaraco]

In GitLab by @jaraco on Feb 15, 2019, 18:24

Thanks Anthony. I'm sort-of inclined to push back on this use case. One of the things we're trying to do with importlib_metadata is limit the API interface to the most essential use-cases (and thus keep the design simpler).

I wonder if that test could be re-written to something like this:

def test_console_scripts():
    """
    Pytest should expose two console scripts, 'pytest' and the
    deprecated 'py.test', and they should both point to the
    same target.
    """
    all_scripts = importlib_metadata.entry_points()['console_scripts']
    named = {
        ep.name: ep for ep in all_scripts
    }
    assert named['pytest'].value == named['py.test'].value

I suspect it's not important to test that pytest doesn't expose any other entry points (as the previous test did).

And I do see that with distribution('pytest'), you're able to evaluate the entry points for the package that way. That seems like a suitable, lower-level way to inspect all entry points of a package under test.

So I'd like to proceed with the change proposed in !39 (remove the name parameter) and include this use-case in #45 as the best approach for getting entry points by Distribution.

[jaraco]

In GitLab by @asottile on Feb 15, 2019, 22:30

I wonder if that test could be re-written to something like this:

the problem with that is ~anything could define those entrypoints and the test would false-negative. I really want to inspect pytest's entrypoints and nobody else's

I'm completely ok with going through distribution(...).entry_points(...) -- the reason I made this issue in the first place is every other api exposed seems to be a shortcut for distribution(...).x() except entry_points (despite there being a method on Distribution by the same name)

[jaraco]

In GitLab by @asottile on Feb 16, 2019, 24:49

Another slight cosmetic issue -- the example needs to be:

importlib_metadata.entry_points().get('console_scripts', ())  # or whatever your entry point is

which seems only slightly clunky

[jaraco]

In GitLab by @jaraco on Feb 16, 2019, 15:15

every other api exposed seems to be a shortcut for distribution(...).x()

That's actually a pretty good argument for supporting it filtering by distribution.

[jaraco]

In GitLab by @warsaw on Feb 24, 2019, 24:11

@jaraco This seems like a valid enough use case, and since entry_points() already accepts that argument, and @asottile tried to use it for the "obvious" purpose, it seems worth supporting. In this case, I think that provides a more consistent API than having to drop down to the lower level API.

[jaraco]

In GitLab by @asottile on Feb 24, 2019, 01:11

I think even with that parameter the api would be confusing, like is it "entry points for a specific distribution" or is "entry points in a specific category" -- it might make sense to have separate non-ambiguous apis for those others, I think removing the parameter for the current api is ok.

maybe entry_points_for_distribution and entry_points_of_type apis? (please bikeshed on the names that I didn't put very much thought into!)

[jaraco]

In GitLab by @jaraco on Feb 25, 2019, 24:49

closed via merge request !39

[jaraco]

In GitLab by @jaraco on Feb 25, 2019, 24:49

closed via commit bcfb9f5