PEP 723: use a new `[run]` table instead of `[project]`?

Oh, definitely! My team will keep me honest on this one. :slightly_smiling_face: It’s also why I’m trying to not guide the discussion too much as I want to avoid personal bias as much as possible.

Your package/distribution requirements are a part of what’s required to run your code. Thinking in terms of constructing an environment to run your code with, you need a Python interpreter and any dependencies your code depends on. Your requirements make up the latter need, while both combined make up what’s required. And sense you can’t infer one from the other, some folks are asking for a way to specify the required Python version.

Somewhat. I view this discussion more as whether @ofek and @pf_moore can agree on a joint PEP and what that might entail, while the other topic is more about the details of what a new TOML table might look like to specifying what applications need to run, of which single-file scripts can be viewed as a subset and quite possibly would get used by the hypothetical joint PEP.

To be clear, I am personally very much looking at this whole thing as a PEP delegate optimizing for use case 2. If other use cases are somehow enabled by the outcome then that’s a bonus, but I am not optimizing for it. For instance, the reuse of TOML would be for simplicity of explanation of the format (assuming we find out beginners don’t find learning TOML difficult), and for reuse of knowledge/documentation where you learn something once and it works regardless of where you write it down. I personally don’t view TOML as important to empower avoiding creating a full-blown project directory for as long as possible.

Various authors have been @ mentioned, but if we don’t hear from them by the end of the week I will go and ask the projects via their issue trackers.

FYI the Python Launcher for Unix will support the outcome of all of this. Developing subcommand support for the Launcher was to open up two specific use cases where there wasn’t a standard and thus I didn’t feel comfortable baking into the py command itself: a py pip command that automatically creates a virtual environment as needed, and a py run that was going to do with pipx run supported via your change. But if this all becomes a standard I will simply embed the py run command since it will be following a standard not be something that needs to evolve as a separate thing where I have to try and match some other tool.

And in this specific case, the required Python version becomes an implicit filter on what Python interpreter to use to construct the environment to run the code with.