Thanks Brett for making this decision. I think this will make a big difference for people who want to use 3rd party Python packages but find managing virtual environments more of an overhead than they are comfortable with. Thanks to Ofek for championing the TOML format, and for his willingness to look for a compromise solution (even if we didn’t manage to achieve that in the end).
I also agree with Ofek’s comments about the user study. Whenever I see this sort of work done, I’m amazed by how much can be gained from it - we need to do more of this sort of thing, and I am really grateful to Courtney for putting the study together and interpreting the results.
Hopefully, someone will be able to find the time to implement PEP 723 for pipx now. The current support for declaring dependencies is still unreleased, and it would be great if we could avoid the transition cost of releasing it and switching to PEP 723 shortly afterwards. PEP 723 support in pip-run would also be good, but we can’t avoid a transition there, as the existing mechanisms have been around for some time.
I’m not 100% sure what you want from me here. My view is that PEP 723 doesn’t require us to add [run] to pyproject.toml, but places specific requirements on any PEP that does so. Are you suggesting that we extend this to add [run] to pyproject.toml right now? Because if so, then I do have some concerns as I don’t see what the intended semantics would be - PEP 723 quite correctly didn’t specify them (it defines semantics specifically in terms of “running the script”), so we need some form of standard to fill that gap.
I’m fine with “[run] in pyproject.toml” being a new PEP, which I have no problem being PEP delegate for. And I’m fine with PEP 723’s statements being a pre-requisite for any such PEP. But unless I’m missing something, I don’t think we have enough detail to introduce [run] into pyproject.toml without its own PEP. If you’re suggesting otherwise, then I guess I would like you to describe how you expect it to work.