PEP 639: Improving license clarity with better package metadata

ofek · May 12, 2021, 2:11am

Has there been any progress on this?

cdce8p · May 23, 2021, 10:08am

setuptools v57.0.0 was just released which includes initial support for the License-File metadata field.

github.com/pypa/setuptools

Add ``License-File`` field to package metadata

pypa:main ← cdce8p:license-file

opened 07:04PM - 17 Apr 21 UTC

cdce8p

+123 -54

## Summary of changes This PR adds the ``License-File`` field to the package …metadata. Although not yet part of the official metadata spec, including this field will enable third party tools easier access to all included license files through `importlib.metadata`. This is especially useful if a file doesn't have an easily recognizable name or is in an unusual location. `setuptools` already parses the `license_file` and `license_files` options and cross-references them with all project files to see which ones should be included. With this change, the result of that would be made available for others to use as well. Closes #2631 -- For reference: [PEP 639](https://www.python.org/dev/peps/pep-0639/), currently still in a draft, plans to add the `License-File` field to the metadata spec, [link](https://www.python.org/dev/peps/pep-0639/#license-file-multiple-use) -- Example use case ```py from importlib import metadata meta = metadata.metadata('my-project') project_files = metadata.files('my-project') license_file_paths = [ path for path in project_files if str(path) in meta.get_all('License-File') ] ``` ## Open questions **1. What should the value of `License-Path` be for files not in main project directory?** From a technical standpoint it would probably be best to use the actual relative path and mirror that in the `.dist-info` directory. However, at the moment `wheel` flattens the folder structure and just puts all license files into `.dist-info`, AFAIK. This could lead to name conflicts. **2. Should license files be copied into the `.egg-info` directory if the legacy install is used?** **3. How should `license_files` and `MANIFEST.in` continue to work together?** At the moment, the `MANIFEST.in` is parse at the end and thus overwrites all previous file includes. However, `license_files_computed` will only look at the `license_file` and `license_files` options (unless we parse the manifest there too). That means that the `License-File` field might contain files that are later excluded by the manifest. -> I would recommend to change the behavior so that the `license_file` and `license_files` options take precedent over the manifest. A license file is most likely excluded by accident anyway. Additionally, specifying `license_files =` (without any values) won't add any default patterns and thus not match any license files. ## Pull Request Checklist - [x] Changes have tests - [x] News fragment added in [`changelog.d/`]. _(See [documentation][PR docs] for details)_ [`changelog.d/`]: https://github.com/pypa/setuptools/tree/master/changelog.d [PR docs]: https://setuptools.readthedocs.io/en/latest/development/developer-guide.html#making-a-pull-request

pradyunsg · May 24, 2021, 5:08pm

Secondly, is there any way of fixing this so it stops spamming me (and others)?

IIRC, this was a GitHub regression. Getting notifications like this when forks are updated was NOT an intended behaviour and, a few weeks ago, that regression was fixed again.

ofek · June 3, 2021, 6:09am

@CAM-Gerlach Would you still be open to updating the PEP? https://github.com/python/peps/blob/master/pep-0639.rst

CAM-Gerlach · June 4, 2021, 10:08am

Hey, thanks for the ping and sorry for the lack of engagement lately; I was hoping to get @pombredanne 's feedback and then I was dealing with NASA and family stuff. Yeah, I can take a crack at drafting a PR this weekend, based on the proposals/task list above and the subsequent discussion, though I’ll definitely need feedback from reviewers much more experienced with packaging, like you and @pf-moore , to make sure the details are all in order. This would include the mechanical/reformatting/framing, etc. changes, and implementing and summarizing the rationale for the changes everyone seems to already agree on (e.g. a new License-Expression field instead of re-using the existing field).

As for remaining issues, it sounds like those who have chimed in so far all basically agree that the goal is for the new License-Expression field to replace the existing License field and Trove classifiers, with a some sort of deprecation period followed by removal. However, while I’ve proposed a plan for deprecation in 2.3 followed by a removal in a notional 3.0 that aligns with what people have brought up here so far, it definitely seems like there should be more discussion and feedback on that especially from packaging experts and tool maintainers, and there are a number of details we’ll need to iron out. Given that with the other major changes, the PEP will be incomplete without at least a draft deprecation plan, I guess can add what we have so far as a starting point, any immediate problems ironed out during PR review and then we can iterate further here, but any immediate feedback on that would be most welcome. Thanks!

ofek · June 22, 2021, 4:06am

Could you link the PR here?

ofek · July 7, 2021, 3:56pm

@CAM-Gerlach Hello again! I’m not sure if you saw the previous message, but did you have a chance to open that PR?

CAM-Gerlach · July 7, 2021, 9:32pm

Hey, sorry for the long delay @ofek and thanks for the ping! I’d drafted a message that I evidently never sent, but aside from NASA stuff I just had a close friend pass away after a battle with cancer and I’ve been kinda disconnected for a while, and didn’t see a notification about your previous one. I’ll try again to allocate some time this weekend for it, and will ping here as soon as I have something somewhere public. Thanks!

ofek · July 7, 2021, 9:41pm

Ah no worries, I’m very sorry for your loss.

I’ll be glad to help review whatever you come up with. Again, thank you!

hroncok · November 11, 2021, 12:56pm

The referenced version number should be updated to 2.3 and the updated version to 2.2 throughout the PEP, and 2.2 added to the references section…

CAM-Gerlach · November 14, 2021, 5:38am

Sorry for this falling off my radar (and thanks for the pings @ofek ); I got a bit overwhelmed with everything that had piled up when I got back and had to incrementally spin things up again project by project. I can start with the more straightforward and mechanical changes listed in my prior comment (aside from the version updates, per @pf_moore 's comment, which will instead be removed entirely) in a PR so we have something to start with, and then can propose one or more on top of that for discussion with the more substantive changes we’ve discussed.

CAM-Gerlach · November 14, 2021, 5:43am

Hey, thanks for getting started on this! I really hate to be the one to mention this when I’ve been so delinquent in helping with this myself until now, and its my fault for not updating that message back when I could and thus misleading you, but @pfmoore 's response to my comment, that is actually the one part that shouldn’t done, and instead all the references to the metadata version should be removed and the PEP reformatted to look like PEP 643. I’ll mention that in a review and drop a PR shortly doing that instead.

CAM-Gerlach · November 29, 2021, 4:53am

Welp, it ended up being far more of a project than I anticipated, but at long last, the big PEP update you’ve all been waiting for (and more)! I ended up reading all the issues, all the specs, this whole discussion and taking a very deep dive into the packaging world and learned way more than I ever thought (though perhaps as much, gained an appreciation for how much deeper still this ocean goes).

I’ve carefully organized the commit history into logical, atomic, high-level changes, to hopefully make it relatively easy to follow and review. Here’s a high-level summary; for the full details, expand the <details> dropdown on the PEP.

github.com/python/peps

PEP 639: Make requested additions and changes, add additional helpful info, reformat, update and copyedit

python:master ← CAM-Gerlach:update-pep-639

opened 04:51AM - 29 Nov 21 UTC

CAM-Gerlach

+2302 -593

As requested and discussed at length on the [Discourse thread](https://discuss.p…ython.org/t/pep-639-improving-license-clarity-with-better-package-metadata/2154/170), this is a thorough rewrite of PEP 639, to reflect the numerous additions (PEP 621 metadata, deprecation guidance), changes (use ``License-Expression`` field instead of ``License``, license file handling), updates (to many tools, specs, links, best practices and docs it references in the two+ years since its creation) and reformatting (as a standalone PEP rather than a spec update, inline links per #2130 , headings, various formatting/PEP 12 issues). Additionally, adds examples, user scenarios and a terminology section (as mentioned there), comprehensively documents the many ultimately rejected ideas suggested during the course of that thread, expands several of the other sections, resolves many issues and inconsistencies in the text, adds a number of internal links for easier navigation and copyedits for grammar, phrasing, clarity, tone and correctness. To note, the diffs look much messier and more extensive than they actually are, due to the reorganization and, particularly, the rather antiquated hard-wrapping (rather than, e.g., sentence wrapping) that leads to small changes cascading the appearing to "change" an entire paragraph. **Note to committers**: Once this is ready, a rebase-merge would be appreciated, to preserve the carefully arranged commit history organizing the changes into digestible, logical units, while still keeping a linear git history, but I understand if repo policy prevents that. @pombredanne , if you see this, would you prefer if I added myself to the authors list, so I can continue to help champion, refine and implement this PEP? We all haven't heard from you about it in many months, so I'm happy to take care of your baby for you! Pinging involved parties (also posted on the thread, ofc): @pombredanne @pfmoore @ofek @hroncok @kpfleming @di @pradyunsg @brettcannon @uranusjr High-level summary of changes: <details> All the requested/needed changes have been implemented, including: * [x] Rewrite to reflect adoption of a standalone `License-Expression` field instead of the `License` field, as agreed here * [x] Add detailed guidance for deprecating the legacy license metadata, as discussed here * [x] Add requirements for PyPI validation of new fields, per consensus here * [x] Add full coverage of PEP 621 metadata, as requested by @pf_moore * [x] Add open issue discussed here regarding filling legacy license field * [x] Restructure PEP as standalone rather than spec update per @pf_moore * [x] Update and expand other sections to reflect the changes above * [x] Implement basic formatting cleanup and fixes mentioned above In addition, I've addressed the following issues I found during the process: * [x] Add many additional missing ambiguous license classifiers and further guidance on handling them * [x] Update to reflect tool, spec, link, doc and best practice changes since its drafting two years ago * [x] Add minor clarifications to document the license files in the sdist, wheel and install project specs * [x] Specify that `license_files` should match the subdir layout of the source as requested on wheel and Setuptools issues * [x] Specify proposed ``license_file`` subdirectory as suggested on wheel and setuptools issues * [x] Move the examples and other non-normative content out of the specification * [x] Add, fix and improve links, references and more * [x] Copyedit PEP for grammar, phrasing, tone, clarity and correctness issues Finally, I've added some additional non-normative content that should be useful here: * [x] Add terminology section, and use terms consistently * [x] Describe in detail the rationale for the implemented structure and the alternative ideas proposed here and elsewhere * [x] Add User Scenarios section with guidance/FAQs for ordinary package authors * [x] Add/expand both simplified and detailed end to end examples * [x] Expand several other sections with additional detail and clarifications </details> Full detailed chronological description of changes: <details> * [x] Restructure PEP to reflect form used in PEP 643, framing it as a standalone specification rather than a canonical incremental update of the actual core metadata spec itself, as proposed on Discuss thread and confirmed by @pfmoore * [x] Update PEP title and metadata * [x] Remove/replace references to the past and proposed versions of the metadata spec * [x] Revise relevant sections (Abstract, Motivation, Rationale, Specification, References, etc) accordingly * [x] Add a mention of this being for Core Metadata 2.3 * [x] Implement basic formatting cleanup and fixes * [x] Conform to consistent Title Case and names for headings * [x] Use ordered vs. unordered lists appropriately * [x] Capitalize words after list items * [x] Fix other minor formatting, spelling, capitalization and syntax issues * [x] Rewrite PEP to reflect adoption of a standalone `License-Expression` field instead of the `License` field, as agreed on the Discuss thread * [x] Rewrite the Abstract, Goals, Non-Goals Motivation, Rationale, and Backwards Compatibility sections to state that the same field is not being re-used, and explain why adding a new one was chosen * [x] Revise the Specification sections and the How to Teach This and License Expression Example sections to reflect the various changes in field use and tool recommendations * [x] Update references to the `License` field to refer to the `License-Expression` field, where appropriate * [x] Replace the item describing the design and rationale of adding a new `License-Expression` field with that of re-using the `License` field in the Rejected ideas section * [x] Rewrite and expand guidance on tool handling and conversion of legacy license field and classifiers, and include in a new dedicated section * [x] Add rejected ideas for deprecation, alternatives and other things discussed earlier and later on discourse * [x] Expand and update the PEP to reflect tool, spec and documentation changes since its initial drafting, fix link rot and follow current best practices * [x] Rewrite the the "License Files in wheels and setuptools" section to reflect ``license_files`` being supported by both tools and both wheels and sdists and Include the additional license file names I added in pypa/wheel#251 * [x] Mention ``License-File`` support in package metadata added in pypa/setuptools#2645 based on this PEP * [x] Revise and expand PyPA sample project section to include PyPA guide and tutorial and reflect updates * [x] Update the in-depth examples to be accurate for modern setuptools and use best-practice license names * [x] Fix broken, redirected, outdated, non-HTTPS and non-perma links * [x] Update License Core Metadata section in Appendix 2 to latest * [x] Update SPDX license list version to current 3.15 from 3.10 * [x] Add changes to PEP 621 metadata, as suggested by @pfmoore , restructure accordingly and greatly expand examples * [x] Add `expression` and `files`, deprecate `license` and `file`, and describe tool recommendations and examples thereof * [x] Specify dynamic field handling * [x] Reorganize sections and make headings shorter * [x] Greatly expand examples and move out of core specification * [x] Explicitly mention that tools may back-fill the License field * [x] Further specify and clarify license-file handling, in PEP 621 and core metadata * [x] When missing * [x] Requirement to include * [x] Path separators * [x] Glob patterns * [x] Default value * [x] Tool recommendations * [x] Clarify `.dist-info` vs `.egg-info` / sdists vs wheels * [x] Add many additional missing ambiguous license classifiers and further tool guidance on handling them * [x] Specify ``license-expression`` and ``license-files`` as separate PEP 621 fields, greatly refine dynamic field handling and add many rejected ideas * [x] Update and reorganize PEP 621 keys specification and examples * [x] Add and update dynamic handling for keys * [x] Describe previous approach under Rejected Ideas * [x] Update backward compat section to include PEP 621 * [x] Describe previous approach under Rejected Ideas, mentioning simplifies spec, explicitness, consistency and and dynamic, and avoiding bikeshedding, and update other * [x] Describe other rejected syntax and semantics for the keys and values * [x] Specify that `license_files` should match the subdir layout of the source as suggested on issues * [x] Update specification accordingly (source, sdist, wheel and installed) * [x] Update examples to include output license file paths * [x] Describe previous status quo approach in rejected ideas * [x] Add proposed ``license_file`` subdirectory as suggested on issues * [x] Update specification and examples * [x] Move license file subdir from open issues to rejected ideas * [x] Rejected idea(s) for storing license files under `data` or new sys.prefix * [x] Add section explicitly describing updates to the project format/distribution specs * [x] Add requirements for PyPI validation of new fields, per consensus on Discourse * [x] Update spec to include * [x] Add rejected idea for not doing so * [x] Add additional open issues and rejected ideas from Discourse/issues * [x] Open Issue: What to do about backfilling? Require? Or drop as unnecessary? * [x] Rejected Idea: license expressions on a per distribution basis * [x] Add User Scenarios section for ordinary package authors * [x] Private package * [x] I don't care about licenses * [x] Creating a new package * [x] Existing package * [x] Packages under multiple licenses * [x] Update general sections to reflect changes * [x] Abstract * [x] Goals/Non-Goals * [x] Rationale: Simply keep extending PyPI classifiers * [x] Backward compat * [x] Other sections * [x] Add definitions section (and use consistently): https://packaging.python.org/glossary/ * [x] Packaging Tool (Tool), Build tool, Publishing Tool * [x] Source metadata, Output/Built/Distribution metadata (not Binary) * [x] License Expression, License Classifier, License identifier * [x] Field, Key (Subkey, Table) * [x] Package / Distribution / Artifact * [x] Other correctness and consistency cleanup * [x] Add, fix and improve links, references and more * [x] Use inline links instead of footnote references, per issue #2130 * [x] Add internal and external links where called for by the text * [x] Fix existing links and syntax to be more clear, direct and consistent * [x] Make a number of related copyedits, improvements and fixes in the text * [x] Copyedit PEP for minor grammar, phrasing and style issues and proofread for typos and errors </details>

All the requested/needed changes have been implemented, including:

Rewrite to reflect adoption of a standalone License-Expression field instead of the License field, as agreed here
Add detailed guidance for deprecating the legacy license metadata, as discussed here
Add requirements for PyPI validation of new fields, per consensus here
Add full coverage of PEP 621 metadata, as requested by @pf_moore
Add open issue discussed here regarding filling legacy license field
Restructure PEP as standalone rather than spec update per @pf_moore
Update and expand other sections to reflect the changes above
Implement basic formatting cleanup and fixes mentioned above

In addition, I’ve addressed the following issues I found during the process:

Add many additional missing ambiguous license classifiers and further guidance on handling them
Update to reflect tool, spec, link, doc and best practice changes since its drafting two years ago
Add minor clarifications to document the license files in the sdist, wheel and install project specs
Specify that license_files should match the subdir layout of the source as requested on wheel and Setuptools issues
Specify proposed license_file subdirectory as suggested on wheel and setuptools issues
Move the examples and other non-normative content out of the specification
Add, fix and improve links, references and more
Copyedit PEP for grammar, phrasing, tone, clarity and correctness issues

Finally, I’ve added some additional non-normative content that should be useful here:

Add terminology section, and use terms consistently
Describe in detail the rationale for the implemented structure and the alternative ideas proposed here and elsewhere
Add User Scenarios section with guidance/FAQs for ordinary package authors
Add/expand both simplified and detailed end to end examples
Expand several other sections with additional detail and clarifications

@pombredanne since we haven’t heard from you in a long time, do you mind if I add myself as an author so I can help champion, refine and implement your excellent work?

ofek · November 29, 2021, 8:20pm

This is awesome, thanks!

I share @uranusjr’s opinion from https://github.com/python/peps/pull/2164#discussion_r758083210

PEP 621 specifically left room in the license key, so we don’t need to deprecate it. We only need to deprecate license = {text = ...} and license = {file = ...} , and define meaning to license = "MIT" . No new [project] keys are needed.

I haven’t followed this thread as closely as you have but I also thought we all only wanted to drop the License metadata field.

I’m finishing up Hatch v1 beta and currently it follows PEP 621 – Storing project metadata in pyproject.toml | peps.python.org

A practical string value for the license key has been purposefully left out to allow for a future PEP to specify support for SPDX [6] expressions (the same logic applies to any sort of “type” field specifying what license the file or text represents).

So I thought license key as a string would be the new License-Expression metadata field.

Also, perhaps most importantly, I don’t want (users) to have to type license-expression

CAM-Gerlach · November 29, 2021, 10:05pm

Hey, thanks for your kind words!

As I mentioned in my reply to him there (with a few minor clarifications):

Actually, this was exactly the original approach I took here (see 4871854 ), later revised to split the license-files out into a top-level key while keeping the License-Expression field mapped to the license key, and then further revised to split them both (see 88cba0c ). In practice, when I considered it carefully, the first, and to a somewhat lesser extent the second approach provided to be distinctly inferior [to that ultimately taken] for a number of reasons, and quite possibly unworkable (due to the interaction with the dynamic key, depending on exactly how one interprets a rather imprecisely specified passage in PEP 621), while the only downside of the present approach was 1-2 more top-level keys.

I spent a substantial amount of time carefully considering the alternatives here, and thoroughly address both of these in great detail in the Rejected Ideas section; see the Add expression and files subkeys to table and Define license expression as string value items under the Source metadata license key subsection.

As for the hybrid approach he then suggested in his subsequent reply (separate license-file field, but license string value meaning license expression), which is at least a somewhat more viable alternative:

In fact, following that which you previously proposed, this was my second approach here too However, upon implementing it, it still ran into less serious versions of some of the same issues as the previous, including mapping two distinct metadata types to the same key, inability to specify which was marked as dynamic, and creating additional inconsistency between core metadata, PEP 621 and setup.cfg/other tool formats. On top of that, it creates potential for serious user confusion and ambiguity, since it means license maps to completely syntactically and semantically different fields depending on the config format, and is much less explicit to authors, readers and consumers that it is intended to be a SPDX identifier/expression. See Define license expression as string value in the Rejected Ideas for more details.

If you’re still not sure about the rationale, I highly encourage reading the Rejected Ideas sections mentioned that explain the reasons for these choices, or if it would be more convenient (for you or anyone), I’m happy to summarize them in bullet point form here. I certainly would appreciate feedback on the flaws you find in that reasoning, points you see differently or things I haven’t yet considered.

Maybe I missed something somewhere when I re-read the thread (I did spend a lot of time doing so, haha), but as far as I’m aware, we haven’t yet discussed what exactly to do for the PEP 621 source metadata, aside from Paul mentioning that it should be added to the PEP. The current approach taken for the source metadata, among other things, most closely matches that agreed upon by all for the core metadata, though as mentioned I myself in fact first tried the exact approach @uranusjr suggested, and then the exact approach he suggested as a followup, and only afterward revised it when the multiple issues and downsides became apparent.

Yeah, but this is just a non-normative potential future suggestion, not part of the specification. That said, if having to revise the Hatch implementation would be a blocker to supporting this, I can offer my help; all other reasons aside, it might be around the same or less of my free time to revise the implementation than to do yet another big re-write to change this, assuming it would take <= a few hours in Hatch.

Hehe, well that was the main positive I cited for that approach. But the other practical problems it entails aside, particularly given the spirit, goal and motivation of this PEP, I strongly feel the value of explicitly, readably and unambiguously making it clear to authors, source code readers and tools that the key value is a license expression (and not the confusingly identically named license key in setup.cfg, setup.py, or other tool config, or the License field in core metadata) is worth the extra ≈2-3 seconds required once in a package’s lifetime to type 11 extra characters. After all, per the Zen of Python, “explicit is better than implicit”, “readability counts” and “in the face of ambiguity, resist the temptation to guess”. (Perhaps you could counter with “practicality beats purity”, though I’d argue naming a PEP 621 key the same as a totally different core metadata field than the one it maps too ain’t too practical )

ofek · November 29, 2021, 10:51pm

Oh no! I’m mostly just providing feedback from an implementation POV since I’d posit I’m not the only one who misinterpreted the PEP 621 text/this thread.

I’m assuming Python will be around for many more decades so this is fundamentally my issue: say we get the future we want and everyone is only defining license-expression, why impact UX in perpetuity? It’s small concessions like this that can add up to have an overall negative impact in time.

The vast majority of users do not know the underlying metadata implementation nor do they care (nor should they). They want everything to Just Work in the easiest possible way so they can get along with their day.

I’m happy this is finally happening though, so whatever is decided is more than fine with me!

edit: typo

CAM-Gerlach · November 29, 2021, 11:44pm

Oh no, I don’t mean to imply you (or anyone) had misinterpreted it, sorry! What you suggest (and what I initially implemented) does seem to be roughly, what PEP 621 informally contemplated at the time, but reserved for this PEP to actually consider defining.

Mmhm, that’s a really interesting and thought-provoking point! We do want to keep the long future in mind (with the caveat that this spec, the ecosystem and its needs can also evolve too, such that we don’t want to solely optimize for it). From that perspective, the deprecation concerns with the license key aren’t so important, and with a few changes and restrictions in the spec (including not backfilling the License field, and specifying that the top-level license key being specified automatically means that both License and License-Expression are not treated as dynamic), the mixed fields, conversion and dynamic marking issues should mostly go away, at least within the PEP 621 world.

What’s left is weighing saving a couple seconds once per package (not trivial over all packages, true) against the increased clarity and reduced risk of confusion for authors, readers and consumers (especially new ones) who would benefit from knowing explicitly, readily and unambiguously, without having to guess, remember or dig through the spec/docs, that the value is a license expression—not just a single identifier, a license long name, the full license text, a license file path, free text, etc. From that viewpoint, I still find the latter more compelling overall, but its certainly a lot less decisive and more down to judgement whether we want to prioritize explicitness, readability and unambiguity over brevity.

Also, while it will eventually be removed in an unknown number of years, and weaned off for a few more, realistically I don’t think we can entirely ignore the potential confusion due to the license key in setup.cfg, setup.py and other tool configuration having completely different syntax and semantics and maps to a whole different field than in PEP 621.

Yeah, I agree; you’re right that matching the underlying metadata fields (or even the keys used in other widely used tools) isn’t a particularly compelling reason on its own, and indeed several other PEP 621 keys have different names than either. I do think, though, this one is considerably more problematic since it has the exact same name as a different metadata field, and much more importantly, an existing config key used in most other existing tools for something quite different.

CAM-Gerlach · November 30, 2021, 1:17am

Sorry for the double post, but there actually is another, more serious issue with dynamic and sticking License-Expression under the same key as License that I didn’t explicitly describe here on Discourse, but @domdfcoding reminded me of it with his helpful feedback on the PR —unless there’s a way around it that I haven’t thought of, it would mean that build tools would be prohibited from doing anything in the Converting legacy metadata section unless the existing PEP 621 license key, including both its text and file subkeys, were not only marked dynamic but not present at all (per the specified semantics of the dynamic key), which prevents it from working at all for many/most existing PEP 621 users.

Also, on a related point that also got brought up there, if we require license to be listed dynamic to be backfilled (which, to be fair, causes some serious issues if it does need to be marked as such, to the point where it might be better not to allow backfilling at all), it is inherently mutually exclusive with using the existing license key for license expressions, for the same reasons.

brettcannon · November 30, 2021, 8:28pm

Or your PEP says license is allowed to be back-filled (I’m not saying it’s a good idea specifically, but it’s an option).

CAM-Gerlach · November 30, 2021, 9:37pm

Hey, thanks for the reply, and sorry for the confusing wording above—I edited the post to try to clarify. Basically, as of my PR, the PEP says that tools MAY backfill License from License-Expression, but (in PEP 621 project metadata), license MUST NOT be marked dynamic if license-expression is present (to prevent tools unaware of this specification filling it and producing conflicting metadata). Given there doesn’t seem to be a strong reason to not allow tools to do so, but I also haven’t seen a clear, compelling use case where it is strictly necessary, the PEP at present mostly leaves this as an option for tools, while requiring that they not produce conflicting metadata. This seems to be a reasonable balance that fits with the rest of the spec as it is currently, but I left it as an Open Issue to solicit any more feedback on this approach or potential alternatives.

Just to be clear, its originally @pombredanne 's PEP ; I’ve just been championing, updating and implementing what we’ve decided on it since we haven’t heard from him in a while. I reached out to him again through other channels to get his blessing for this and suggest that I be formally added as a co-author, so I can make sure I can officially help ensure his great work gets merged and implemented in tooling.