Repository navigation
Using entry-point value for non-object references #523
Description
Activity
I briefly read the entry points spec, and it seems to stipulate that the value must be a module or object in a module.
- The idea of (ab)using the entry-point for a metadata file seems neat to me. Would it be OK to accept it as use (even if not common or advertised) or is there a reason against it?
Such a change would require a change to the specification. You'd need to convince the packaging community that this use as valid and worth the tradeoffs. Adding support for this form would dilute the specificity of the EntryPoint (and would be used for concepts other than references to Python objects in the package). My instinct is that if there's a use-case, it should probably be its own metadata format and not shoehorned into the Entry Points format. That said, I don't think the Python Packaging Ecosystem provides a good solution for other metadata files. If it did, you could use importlib metadata to scan metadata files across packages.
2. Raising an error at
EntryPointconstruction itself fails already atimportlib_metadata.entry_points(group="my_group"), which means that a bad entry-point cannot be skipped (unlike if it fails forEntryPoint.load()which may be guarded with a try/except).
EDIT: I just noticed thatgroup=seems to be applied afterEntryPointcreation. So a single bad entry-point will break any project loading entry-points.It's conceivable the validation could be pushed out of the constructor and back into the
.loadoperation. That seems reasonable to me, given that one bad package shouldn't cause all entry points to be broken. On the other hand, it does mean that it becomes possible to construct invalid EntryPoint objects, which seems less than desirable.I'm unsure what's the right choice here, but given that the change was released in a feature release (8.7.0) and not a backward-incompatible release, I'm leaning toward restoring compatibility.
I do actually now think that this use is rather reasonable. I.e. there is a clear advantage to use a metadata file rather than an object and I don't see a downside besides the fact that
.load()does not make sense (i.e. loading it is a bit less convenient).
One could bless this with some format that encodes that it is a toml metadata file and load would deal with that, but it is pretty easy to do either way).About moving the failure: In the end the Python object pointed to can also be incorrect or just not exist. So failing at load time seems fair... just consider it identical to the referred object missing (far more likelg anyway).
napariuses the entry-point value for non-object references, i.e. a file path to load metadata from (i.e. asmodule:file_path).This pattern seemed like a good idea for certain use cases. The main idea is that only reading metadata effectively ensures that we do no costly imports until we actually need to (which may be never).
Now, I noticed that since gh-518 such (ab)use is more heavily policed, since loading will fail immediately and not just when
EntryPoint.load()is actually called.So I suppose I have to comments/questions:
EntryPointconstruction itself fails already atimportlib_metadata.entry_points(group="my_group"), which means that a bad entry-point cannot be skipped (unlike if it fails forEntryPoint.load()which may be guarded with a try/except).EDIT: I just noticed that
group=seems to be applied afterEntryPointcreation. So a single bad entry-point will break any project loading entry-points.Neither of these are big issues, in practice a filename usually conforms (or can be made to conform) to a Python object reference, so there is nothing stopping us from just keeping to use it. But it seemed like a good thing to check in, if just for awareness that this pattern exists in the wild.