PEP 621 implementation (package metadata in pyproject.toml)

[uranusjr]

PEP 621 has been provisionally accepted. The provisional phase has been limited to three months, and it would be best if Flit could try it out in the period to figure out if there are any rough edges.

I compared configurations in both Flit and PEP 621, and here’re fields I think may need work to adopt.

version and description should be marked as dynamic in Flit.

name: Flit by default infers dist-name from module, so we have two choices here, either strictly use it as the direct replacement of dist-name (i.e. continue to recommend module by default and mark name in dynamic), or require name and infer module from it instead.

author: PEP 621 accepts an array (of objects), but Author and Author-email in Core Metadata are single-use, so some combination logic is needed.

home-page: PEP 621 explicitly omitted this. It’s probably easiest to just not use Home-page in Core Metadata at all and only generate Project-URL fields. flit init can generate a urls = { Homepage = "..." } instead.

readme: Flit currently always infers content type from file extension, but PEP 621 allows explicitly setting content type, or even including the text directly in pyproject.toml. This shouldn’t be a problem eventually, but the code to extract the value needs some refactoring.

license: Flit’s current license field is semantically different from PEP 621. I’m not sure if this would be problematic.

[takluyver]

or require name and infer module from it instead.

This was the option I was thinking of. I still like the other way round from the user perspective - the module name is clear before you get to publishing a project - but I don't think it's worth doing odd things with name for.

Flit’s current license field is semantically different from PEP 621. I’m not sure if this would be problematic.

Is the idea that license.text in PEP 621 is similar to Flit's license field, or would you put the actual wording of the license in as a multi-line string?

For flit init we can set license.file to point to the created license file.

[uranusjr]

I believe license.text is intentionally designed to be up for interpretation. The wording is deliberately worded to sound like it should hold verbatim license text because people should use SPDX when that PEP is accepted, but there’s really nothing stopping anyone to use the field in another way.

[takluyver]

I'm making a start on this in the pep621 branch. Not ready for testing yet, though.

[takluyver]

This is hopefully ready to try out now - see PR #393.

[merwok]

The documentation wasn’t updated, right? So people would still use tool.flit.project section instead of the new universal section.

[takluyver]

Yup, my thinking is that it will be experimental for the 3.2 release - I'll mention it in the release notes, but not in the body of the documentation, so early adopters can try it out and we can make any tweaks if necessary. Then hopefully it will be documented for 3.3.

[merwok]

Sounds good, I’ll try it when 3.2 comes out then!

[takluyver]

Thanks @merwok! Hopefully that will be in the next few days. (I'm looking into doing something smarter with writing the metadata files as well, hopefully addressing #387).

[henryiii]

I've added support for generating PEP 621 Flit setup to Scikit-HEP/cookie: scientific-python/cookie#21 - really nice to see two unrelated packages (flit and trampolim) able to read the same input!