Skip to content

Commit 6f72221

Browse files
authored
PEP 794: Weaken the suggestion to use a project's name when Import-Name isn't set (#4576)
1 parent e9e61ac commit 6f72221

File tree

1 file changed

+15
-14
lines changed

1 file changed

+15
-14
lines changed

peps/pep-0794.rst

Lines changed: 15 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -178,27 +178,28 @@ installed. This is a "MAY" and not a "SHOULD" due to some users purposefully
178178
overwriting import names when installation is done in multiple steps (e.g.
179179
using different installers with the same environment).
180180

181-
Tools MAY leave ``Import-Name`` and ``Import-Namespace`` out of the core
182-
metadata for a project. In that instance, tools consuming such metadata SHOULD
183-
assume that when the core metadata is 2.5 or newer, the normalized project name,
184-
when converted to an import name, would be an entry in ``Import-Name`` (i.e.
185-
``-`` replaced with ``_`` in the normalized project name). This is deemed
186-
reasonable as this will only occur for projects that make a new release once
187-
their build back-end supports core metadata 2.5 or newer as proposed by this
188-
PEP.
189-
190-
Projects MAY set ``import-names`` or ``import-namespaces`` -- as well as
191-
``Import-Name`` or ``Import-Namespace``, respectively -- to the normalized
192-
import name of the project to explicitly declare that the project's name
193-
is also the import name.
194-
195181
Projects MAY set ``import-names`` an empty array and not set
196182
``import-namespaces`` at all in a :file:`pyproject.toml` file (e.g.
197183
``import-names = []``). To match this, projects MAY have an empty
198184
``Import-Name`` field in their metadata. This represents a project with NO
199185
import names, public or private (i.e. there are no Python modules of any kind
200186
in the distribution file).
201187

188+
Since projects MAY have no ``Import-Name`` metadata (either because the project
189+
uses an older metadata version, or because it didn't specify any), then tools
190+
have no information about what names the project provides. However, in practice
191+
the majority of projects have their project name match what their import name
192+
would be. As such, it is a reasonable assumption to make that a project name
193+
that is normalized in some way to an import name (e.g.
194+
``packaging.utils.canonicalize_name(name, validate=True).replace("-", "_")``)
195+
can be used if some answer is needed.
196+
197+
Projects MAY set ``import-names`` or ``import-namespaces`` -- as well as
198+
``Import-Name`` or ``Import-Namespace``, respectively -- to an import name that
199+
matches the project name (normalized or not) to explicitly declare that the
200+
project's name is also the import name.
201+
202+
202203

203204
Examples
204205
--------

0 commit comments

Comments
 (0)