Comments (15)
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.
from importlib_metadata.
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.
from importlib_metadata.
In GitLab by @jaraco on Feb 14, 2019, 15:34
mentioned in commit bcfb9f5
from importlib_metadata.
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
?
from importlib_metadata.
In GitLab by @jaraco on Feb 14, 2019, 15:35
mentioned in merge request !39
from importlib_metadata.
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.
from importlib_metadata.
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:
from importlib_metadata.
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.
from importlib_metadata.
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)
from importlib_metadata.
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
from importlib_metadata.
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.
from importlib_metadata.
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.
from importlib_metadata.
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!)
from importlib_metadata.
In GitLab by @jaraco on Feb 25, 2019, 24:49
closed via merge request !39
from importlib_metadata.
In GitLab by @jaraco on Feb 25, 2019, 24:49
closed via commit bcfb9f5
from importlib_metadata.
Related Issues (20)
- Create a Github Security Policy file HOT 3
- PathDistribution normalized name ignores name components after first "-" HOT 6
- Provide a 'diagnose' routine to help users inspect broken environments HOT 1
- ContextualVersionConflict error on jupyter notebook HOT 1
- pypy test has started failing HOT 12
- Rely on zipfile.Path (where viable) HOT 1
- Backport docs changes HOT 1
- Invalid annotation in `SimplePath` protocol HOT 2
- Change build backend to flit-core? HOT 1
- 6.8.0: pytest is failing in tests/test_api.py::APITests::test_prefix_not_matched` unit HOT 3
- PackageNotFoundError No package metadata was found for <myproject> HOT 1
- Question: parsing package names & versions from METADATA file instead of dist-info directory HOT 1
- Provide a helper for "is distribution present" HOT 2
- Mypy tests failing on Windows only HOT 1
- 6.9.0: `DiscoveryTests.test_package_discovery` fails HOT 6
- distributions() finds two packages for editable installs HOT 2
- MetadataPathFinder has `find_distributions` as a classmethod in CPython HOT 1
- Intersphinx mapping for stdlib version
- API incompatibility with `importlib.metadata` (or at least the API is not type-safe?)
- AttributeError changed to AssertionError for invalid identifiers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from importlib_metadata.