Tools MAY leave Import-Name and Import-Namespace out of the core metadata for a project. In that instance, tools consuming such metadata SHOULD assume that when the core metadata is 2.5 or newer, the normalized project name, when converted to an import name, would be an entry in Import-Name (i.e. - replaced with _ in the normalized project name). This is deemed reasonable as this will only occur for projects that make a new release once their build back-end supports core metadata 2.5 or newer as proposed by this PEP.
It took me some time to work out that the normalisation rules here are well defined. To make sure I understand, (1) the project name is normalised as per the spec and then (2), hyphens are replaced with underscores. If I understand correctly, that would make the normalisation do the wrong thing for a project like flufl.enum, as the assumption would be that the name flufl_enum would be installed. So projects like these would need to explicitly set their metadata to get the correct results.
I’m fine with this, I just wanted to be sure I’ve interpreted the intent correctly.
As this is a new field for the core metadata and a new core metadata version, there should be no backwards compatibility concerns.
I don’t think that there’s any semantic difference between a project with metadata 2.4, and one with metadata 2.5 and no Import-Name/Import-Namespace metadata, but it’s difficult to be sure as it’s not stated explicitly. The reason I care is that if & when metadata 2.6 comes out, I don’t want projects to be in a position where they are forced to adopt Import-Name just so that they can use the new feature in metadata 2.6. To be clear, this isn’t a problem with this PEP as such, it’s simply a consequence of our linear progression of metadata versions[1].
Both of these are minor points that I noticed while reading the PEP. I don’t think they need much debate - at most, clarifying the language in the final documentation of the new fields should be enough.
It first came to my attention with metadata 2.4, which deprecated the old License field, meaning that using License could be treated differently in metadata 2.4+ than it was in 2.3 and earlier ↩︎
Correct because I didn’t think we could guarantee that name would be picked up everywhere since flufl.enum isn’t normalized in general. Plus flufl.enum is a bit ambiguous in terms of whether flufl is a namespace or not.
Correct, only that tools SHOULD assume the project name following the normalized rules is what would have been set in Import-Name. We can change this to “MAY” if that feels better for compatibility.
Is that a difference between 2.4 and 2.5? Are you saying that if a tool sees metadata 2.5 and no Import-Name metadata they SHOULD assume the project name, but if they see 2.4, they should not make that assumption?
Because that concerns me, as it’s a silent change in semantics caused by just changing the metadata version.
I’m concerned that even MAY implies that it’s the expected case. Could we instead say something along the following lines?
If a project has no Import-Name metadata (either because it uses an older metadata version, or because it didn’t specify any), then tools have no information about what names the project provides. However, in practice the majority of projects only expose the project name (normalised as described) and so this is a reasonable assumption to make if some answer is needed.
Just an FYI, the core dev sprints are less than 2 weeks away and I will be traveling for those and some vacation. As such it might take me until some time in October to get the PRs to change the specs at packaging.python.org done (the PR for packaging is just waiting for the spec changes for doc cross-linking). Hopefully that isn’t an issue, otherwise I can try and prioritize it sooner.
