Future plans

[regebro]

Pyroma needs to be updated with supporting modern build systems and tools for Python. This has been rapidly changing the last few years, but it's finally looking like it's stabilized and is maturing, especially with the release of Setuptools 61 last week, that supports PEP621.

This thread is for discussion of those plans.

[regebro]

My thinking looks something like this:

Pyroma 4 will:

• Support PEP517
• Use build.prepare() to get metadata
• Deprecate the old setuptools hack it used before.

Pyroma 5 will

• Drop the setuptools hack
• Remove the fetch_classifiers hack and move to using trove-classifers package
• Use the internal packaging version checks instead of custom checks.
• Change the internal metadata to be PEP621 compatible.
• Include specific tests to officially support build systems like Poetry etc

Pyroma 6:

• Read the metadata directly from pyproject.toml for efficiency
• Either drop setuptools as a requirement, or require setuptools >= 61

Pyroma 4 is currently in beta, a good aim for Pyroma 5 would be summer 2022, Pyroma 6 before end of 2022.

Other ideas:

• Use twine to check the long description syntax (but that requires building a distribution?)

[rusty1s]

Thanks for the updates. It looks like with Pyroma 4, description_content_type rather than long_description_content_type is set in get_build_data, leading to content_type being None here.

[regebro]

Ah, yes, that makes sense. I'll fix that for beta 2. Do you have an example package this happens on that I can double check on?

[rusty1s]

It just happened for me here: pyg-team/pytorch_geometric#4368 (needed to revert back to "3.3"). I made the following change here:

content_type = data.get("long_description_content_type", None)
if content_type is None:
    content_type = data.get("description_content_type", None)

This fixed the error for me. Not sure if this is the best solution though :)

[regebro]

It is correct, but also not. :-D I released 4.0b2, it should fix this.

[rusty1s]

:P Thanks a lot for the quick fix :)

[CAM-Gerlach]

Yeah, this basically comes back to the same naming issues we've discussed previously, which will hopefully be more fully resolved in future versions.

Remove the fetch_classifiers hack and move to using trove-classifers package

Any chance this could get moved up, since its a fully drop-in replacement that should be doable in two-ish lines? Otherwise, you have to maintain your bespoke tooling for another whole major release, which is likely to be more work than just switching now. I'm happy to drop a PR doing so if you're okay with it.

[regebro]

Well, the tooling isn't much work, but yes, if you make a PR then I'll add it to 4.x.

[hugovk]

Remove the fetch_classifiers hack and move to using trove-classifers package

Please see PR #81.

[regebro]

Looks good, thanks!

[regebro]

Ugh, I'm so behind on this...