Use the [project] section in pyproject.toml according to PEP-621

[MartinThoma]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

PEP621 (Storing project metadata in pyproject.toml) and PEP631 (Dependency specification in pyproject.toml based on PEP 508) define a clear way how metadata and dependencies should be stored. Both of them have the status "accepted". It would be good if poetry would use that.

For example, I've noticed that poetry init generates a pretty similar pyproject.toml, but puts the metadata in a poetry-specific section.

[sinoroc]

The status of PEP 621 is still "Draft". But yes, I guess it's a valid request (assuming it actually gets accepted and depending under which form). It might take a while though... the way I see it, there are still too many uncertainties

[MartinThoma]

Uh, interesting. My bad. However, PEP-631 is accepted. Do you see uncertainties there as well?

[sinoroc]

At some point, I thought there was an intention to merge the text of 631 into 621, to avoid having to refer to two documents, since 631 is rather short and unsurprising. Don't know if it will happen, or if it stays as 2 separate documents. I lost track of that conversation. And there are some more points of 621 that are still being discussed.

Now, if I put myself in the shoes of poetry:

• PEP 621 might seem like a step to the side, no big changes forward or backward, but we move from non standard to standard. So probably a slight positive.
• PEP 631 could definitely be seen as a step backwards.

Personally I am curious to see how poetry will handle this. There is always the dynamic escape hatch for dependencies. If I were poetry, I would probably try to offer both dependency notations (the existing poetry notation as dynamic and the new/old PEP 631 one). I had suggested a compromise hybrid notation here but it didn't gain any traction at all (probably because too complex to parse, I don't know).

[MartinThoma]

there was an intention to merge the text of 631 into 621

It's mentioned in the abstract of PEP-0631. However, I don't know when this will happen and where the discussion around that is.

PEP 631 could definitely be seen as a step backwards.

I'm surprised by that. Why do you think so? To me, it seems like a step towards more standardization and thus positive.

I would probably try to offer both dependency notations

Yes, I think that would be desirable just to not break a working setup for anybody. Is the poetry dependency notation more powerful or even different at all?

[sinoroc]

Is the poetry dependency notation more powerful or even different at all?

It's all in the discussions, particularly this one, I don't want to repeat things and take them out of context:

• https://discuss.python.org/t/pep-621-how-to-specify-dependencies/4599

[finswimmer]

The discussion about how the dependencies should be defined within PEP-621 was quite said and frustrating for us as poetry maintainers. But I will not go into details now...

As @sdispater has said somewhere in the discussion, poetry will probably not be one of the earlier adopters of PEP-621 now PEP-631 is accepted. We have a problem here now: On the one hand, we want to support as many standards as possible and on the other, user experience is an important topic for us. And we believe that PEP-631 will be a step backwards compared to what we have now. A dilemma we have to discuss. :(

[stephen-dexda]

PEP 621's status is now provisionally accepted as of 8 days ago.

From the point of view of a package dev., having a build tool-independent metadata specification in pyproject.toml is useful to be able to parse metadata from the file without adding build tool-specific references elsewhere, and without duplicating information.

Use case examples:

• project.scripts.*: when building container images, to determine which file to reference as to be executed.
• project.requires-python: to determine which Python versions to run tests against.
• project.optional-dependencies.test: to install test dependencies.

I have been using/parsing all of the above based on the PEP 621/631 drafts, and duplicating this info in pyproject.toml for now from the tool.poetry sections.

Fundamentally, project metadata is not only used by build tools, so having Poetry support (provisionally) accepted standards for these allows the developer to use the metadata for other cases without duplication, and having this support from Poetry would be fantastic :)

[stephen-dexda]

Additionally, PEP 621 is now referenced at https://packaging.python.org/specifications/declaring-project-metadata/.

[stephen-dexda]

As part of this, poetry version <rule> should bump project.version as well as/instead of tool.poetry.version, depending which is/are present.

[yoursvivek]

Status of PEP 621 is now: Final.

• Announcment by Bret Cannon on python discussion forum.
• PR on python/peps is now merged in master.

[mvaled]

The way I see it, poetry can start by supporting PEP 621. PEP 631 (actually PEP 508) requires some changes in the way versions are dealt with in Poetry (e.g ~= 3.6 instead of ^3.6).

[stephen-dexda]

PEP 621 was updated to incorporate the decision on PEP 631 vs. PEP 633; it requires PEP 508 version strings.