Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Using entry-point `value` for non-object references

Open
#523 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
tooling

Research direction

Start by reading the EntryPoint construction and entry_points(group=...) behavior described in the issue, then inspect the changes from gh-518. Determine whether non-object entry-point values should be accepted and whether invalid entries can be skipped during group selection; done requires a documented decision and corresponding behavior or tests.

Written by the indexing model from the issue text.

Description

napari uses the entry-point value for non-object references, i.e. a file path to load metadata from (i.e. as module: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:

  1. 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?
  2. Raising an error at EntryPoint construction itself fails already at importlib_metadata.entry_points(group="my_group"), which means that a bad entry-point cannot be skipped (unlike if it fails for EntryPoint.load() which may be guarded with a try/except).
    EDIT: I just noticed that group= seems to be applied after EntryPoint creation. 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.

Dominant language
Python
Stars
142
Forks
97
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python/importlib_metadata

All issues in python/importlib_metadata

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.