oh, sorry I just fixed pyproject.toml, I thought it wouldn't conflict, but it seems to. Are you okay to fix conflicts? 🙏

Heh I live to serve. :) JFTR, your change log is getting a bit long, so if you need help to cut it to the latest release LMK.

Ye, might be nice to include just releases after v1 or similar.

I think easiest solution would be to split HISTORY.md, an keep the older history just for https://pydantic-docs.helpmanual.io/changelog/.

Then we can add a link to the end of HISTORY.md along the lines of "For everything else, see here."

Sure that works too, but it feels wrong to me to neuter the OG file. :) Check out how doc2dash does it – it's just a bunch of regexps:

• PyPI: https://pypi.org/project/doc2dash/
• changelog: https://github.com/hynek/doc2dash/blob/main/CHANGELOG.md
• the lines responsible: https://github.com/hynek/doc2dash/blob/f71bdc03fbb41fe51a92cd2843cc27f5c24a2513/pyproject.toml#L131-L145

Makes sense. @ofek if you want to put a magic comment in HISTORY.md <!-- package_description_limit --> after V1, then ignore everything after that, that would be great.

Addressed!

Yes, but does this use the current actual license file, or a generic "MIT" label.

In wheel it's under pydantic-X.Y.Z.dist-info/licenses/

FWIW these are separate problems:

A file called LICENSE (and some others which already led to Fedora packagers pester me about it) is always added courtesy of wheel: https://github.com/pypa/wheel/blob/5edc61d2c6535c380fa278bc83c578fbd5444167/src/wheel/bdist_wheel.py#L450

This is what's controlled by license-files = { paths = ['LICENSE'] } and dnserver wheel has the LICENSE file where it belongs:

The PyPI metadata is set using project.license and has only very recently been fixed by Hatchling (1.9 if I'm not mistaken).

You can see in https://pypi.org/project/doc2dash/ meta section that it shows correctly License: MIT License (MIT). I have also released a few packages with the full license in there.

The PEP-conformant way isn't license = "MIT" but license = { text = "MIT" }, otherwise e.g. VS Code will yell at you that license has to be a dict:

Thanks so much for the thorough explanation @hynek.

@ofek, given all the subtleties here, let's go with the most vanilla and correct approach license = { text = "MIT" }.

That's not what's happening here actually.

1. The only backend that uses https://github.com/pypa/wheel is setuptools. The code is here: https://github.com/pypa/hatch/blob/hatchling-v1.9.0/backend/src/hatchling/metadata/core.py#L614-L615
2. That section on PyPI is not what one may think. It's "License: {license_classifier.split(' :: ')[-1]} ({license['text']})". Notice a Hatch project: https://pypi.org/project/platformdirs/2.5.2/
3. Hatchling is the first to support PEP 639 (specifically the end result of that Discourse thread) which allows for a string and deprecates the table. There are no more blockers for approval other than time.

1. The only backend that uses https://github.com/pypa/wheel is setuptools. The code is here: https://github.com/pypa/hatch/blob/hatchling-v1.9.0/backend/src/hatchling/metadata/core.py#L614-L615

Ugh, back when I was on setuptools, they told me that they can't do anything because it's all in wheel. This will take a few years to untangle I guess… Anyhow, the effect stands since you're using the same patterns. :)

3. Hatchling is the first to support PEP 639 (specifically the end result of that Discourse thread) which allows for a string and deprecates the table. There are no more blockers for approval other than time.

Cool! I'm not one to insist on packaging PEP peculiarities. I just noticed that my editor is yelling at me. :)

Anyhow, I don't mean to derail this any further.

Shall I go back to using the new way then?

I think this is good, but I need to review one more time. Will do on Tuesday.

Thanks so much for this @ofek.

I've tweaked the setup slightly to make it a little more concise and IMO more readable, hope that's okay with you.