Add pyproject-metadata to the PyPA

Hi, I would like to propose pyproject-metadata to be added to the PyPA. Several projects are using it now, and I’d like to phase it out as a personal-only project.

What do you think?

Also, if anyone wants to also help maintain it, please let me know, I’d be happy to add you. It’s not a project that sees lots of movement, but having more eyeballs on things would naturally be better, and help reduce the bus factor.

3 Likes

How is it related to/different from the currently WIP packaging.metadata?

I am not sure yet, but that’s a good point. I haven’t followed all the latest progress there, and the current WIP from what I can see isn’t very complete. But I’d say the main differentiator, right now at least, would be that it has an API for user-defined configurations, and has a very heavy focus on descriptive error messages.

There’s definitely a big overlap though, but I don’t know yet how much, and if the differences would want to be picked up by packaging’s API.

The key differences would appear to be that pypackaging-metadata is focused on the pyproject.tomlMETADATA translation while packaging.metadata is focusing more on the reading/writing of METADATA directly (also assume PKG-INFO when I say METADATA). There has been an ask and proposed PR to at least validate the output from a TOML parse of pyproject.toml for packaging.

So think of it as packaging.metadata is more for installers while pypackaging-metadata seems to be oriented towards build back-ends.

I’m working on it. :wink: Initial processing of METADATA in a very forgiving way is almost ready to go in (couple more tests). After that will be the validation step, and then producing a METADATA file.

Probably not simply because the goals are different. I could see pypackaging-metadata handling pyproject.toml and then using packaging.metdata to do the METADATA file generation.

2 Likes

I would like to know what is the difference in the validation part between pyproject-metadata and validate-pyproject because I use them both in my build backend project. I didn’t do a careful comparison and I wonder whether I can drop the latter one. If pyproject-metadata can handle both PEP 621 parsing and validation then I vote for it being part of PyPA.

Yes, it validates the PEP 621 metadata, but only currently we only report the first error (I opened an issue for that, Report all `pyproject.toml` validation errors at once · Issue #45 · FFY00/python-pyproject-metadata · GitHub). We currently also don’t validate the classifiers (I opened an issue for that Validate classifiers · Issue #46 · FFY00/python-pyproject-metadata · GitHub).

I’ll try to get it fixed/implemented this week, as I need to make a new release anyway.

I would like to revive this request, as the project still seems to be relevant and is still seeing a lot of usage.

Additionally, I’d like to be 100% transparent. Over the past year I haven’t been able to dedicate much time to nonwork related open source projects, and since I have been pinged by multiple people regarding issues related to pyproject-metadata, I would like to apply for financial aid, so that I can prioritize it. I don’t think it being under the PyPA umbrella should be a hard requirement for that, but it would help. I think the request still makes sense independently, though the timing for me reviving the topic is motivated by this.

1 Like

I’ll second this.

@FFY00 Do you want to drop an email requesting a vote on pypa-committers?

2 Likes

Sounds good. If the PyPA doesn’t want to host it, I’d be happy to host it at Coherent OSS · GitHub.

1 Like

Thank you!

The vote passed, so I’ll be reaching out to the PyPA org admins to start the transfer.

2 Likes

Great, so who can get the ball rolling next?

I am pleased to be a maintainer.

1 Like