How would you like to declare runtime dependencies and Python requirements for PEP 723?

Packaging Standards
70

If you go back to my provisional acceptance of PEP 723, I laid out the following reasons for selecting it over PEP 722:

  1. Allowing for [run] to be used in both scripts and pyproject.toml means simpler docs as the semantics of the keys only need to pe explained once

  2. … allows for easier transitioning

  3. Parsing is simpler since TOML is a standard

And so I made the acceptance of PEP 723 conditional on having pyproject.toml symmetry.

But then a few things happened. First, I came up w/ a simplification of what TOML format to support. Second, @pf_moore said he would have accepted the simplified proposal as a PEP 722/723 compromise (as well as other suggestions). Third, I came to think that I care more about the pyproject.toml connection more than most.

This led to my poll about options regarding PEP 723. Those results seemed to suggest I was right about me carrying more than others about pyproject.toml support. Then @pradyunsg posted his strawman take of option 2 which @pf_moore also liked.

So what’s wrong w/ option 2? From a quick glance it suggests that if option 2 had been around when PEPs 722 and 723 were being formulated that it would have been a single PEP and my life as PEP delegate would have been way simpler :sweat_smile: . But the wrinkle in all of this is Ofek wants a table to encompass everything. And I do get that desire from an organizational perspective and potentially ease of expansion in the future. It would require separate # /// sections for any other subsequent table, though, if it was meant to implicitly suggest some TOML table.

Pragmatically, I think what @pradyunsg proposed is a good solution. Something I saw in the user studies for the PEPs is that users looked at the table declaration sideways and then just chaulked it up to being required for some reason they just happened to not know. Now that’s not bad, but it isn’t great either. With Pradyun’s proposal, it’s a bit more straightforward, especially by calling the section “script” instead of “pyproject”. And if we are aiming at beginners while trying to make tooling around this easier, then I think I need to let go of my desire to have symmetry with pyproject.toml to lean into the simplicity aspect more. I think changing the section name definitely helped me let go of things and view this as a more isolated thing that has the potential to have symmetry with pyproject.toml (even if PEP 735 and dependency groups lands, I still think having a way to define Python requirements would be useful in pyproject.toml).

So, if @ofek is okay with the changes (please explicitly say yes or no, Ofek), I would like PEP 723 to be updated with Pradyun’s proposal:

  1. Drop the [run] table and make dependencies and requires-python top-level
  2. Rename # /// pyproject to # /// script

That would lead me to accepting PEP 723 unconditionally. This should also allow pipx, if it wants to, to maintain backwards-compatibility with what it has already shipped (but this was not a consideration in this decision, it’s just a nice side-effect).

I know @pf_moore mentioned above that he would be willing to help @ofek make the requisite changes to the PEP; hopefully Paul’s generous offer still stands if Ofek doesn’t have the time.

19 Likes