It’s not just submitting a new PR, it’s getting the project to agree to the change. Luckily, in the case of pipx, the current code isn’t in a release, so there’s no major backward compatibility issue.
With pip-run, though, there’s already two different formats supported in production, so you’d need to agree with them how to handle the migration, and how to deprecate the old format(s) - presumably the goal would be for them to support the new PEP as the primary approach. (I know you didn’t offer to do the work on pip-run, but someone would need to). As a starting point, it would be worth getting @jaraco’s views here.
-1 on anything referring to pyproject.toml. At best this data will be the same as (part of) the data stored in pyproject.toml. But this is a distinct data store, and should be represented as such.
But I agree, this needs sorting out. We shouldn’t start assuming there’s going to be a unified proposal only to discover that the authors can’t agree on the format. I think my only constraints are that it must be in a comment, and it must not refer to pyproject.toml. It’s possible that I may find I have reservations over other points, but I can’t think what they would be in advance.
I know this may sound demanding on my part, but please remember I’ve already conceded on a significant issue, namely the use of TOML. And that’s in spite of the fact that no-one has actually provided a convincing response to the arguments I put in PEP 722 against it. So I feel I have the right to draw the line somewhere. After all, if we end up not comfortable with a compromise, we can still go back to two proposals. I’m trying to avoid that, but there are limits beyond which I’m not willing to go.
Please clarify what you expect tools to do with it, and confirm that pipx and pip-run are able and willing to support it. I’m not comfortable dictating behaviour (even in the form of a “SHOULD” requirement) that the two existing tools that implement this won’t support.
This discussion originally started as purely an exercise in standardising existing behaviour. In that form, it’s a very different process than defining new behaviour that we expect tools to implement. And I don’t want to do the work of getting buy-in for new behaviours, but nor am I willing to put my name to a proposal that defines behaviours without getting that buy-in.
If you prefer not to go with a comment form, please say so and we can go back to having two PEPs. I don’t want to spend any more energy trying to form a compromise if you aren’t willing to accept the data being stored in a comment.
Maybe you’re right and a variable assignment is a good way to go. But you’ve not convinced me, and I sense there’s a lot of others who don’t like the idea either. But if you want to stick with it, it’ll be Brett’s decision, not mine.
To be extra-pedantic, it needn’t. It could look like
run.dependencies = ["..."]
That was one of my objections to TOML - there’s lots of ways of saying the same thing, and for the target audience (at least the audience I’m targeting) that’s a source of unwanted complexity.