-
-
Notifications
You must be signed in to change notification settings - Fork 365
Description
Description
Opening this to discuss the implementation I've already started in #2179.
AFAICT, the only gap at the moment of writing between the implementation and the spec is the following
in practice the majority of projects have their project name match what their import name would be. As such, it is a reasonable assumption to make that a project name that is normalized in some way to an import name (e.g.
packaging.utils.canonicalize_name(name, validate=True).replace("-", "_"))can be used if some answer is needed.
It's unclear to me if this is the responsibility of the build backend, or of the installer. IMO, it's the latter and the backend should not try to be too smart about adding a default Import-Name, but I'd like to read some opinions.
Use case/motivation
Allow projects to declare import-names/import-namespaces according to PEP 794. The full motivation for why the ecosystem will benefit from this is better explained in the PEP 🙂.
Related issues
- The existing PR: Support Metadata 2.5 (PEP 794) #2179
- A different Core Metadata bump: Update the default version of core metadata to 2.4 #1790
Are you willing to submit a PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow the Python Software Foundation's Code of Conduct