I will only respond to this because I think it actually condenses the core of the issue under discussion: where we want to be in 10 years, what world we’re trying to build.
In my ideal packaging world, there is one tool that
- most people use, beginners and advanced users alike (but it will never be used by everybody, and that’s fine)
- can run scripts
- can run REPLs
- can install Python and manage Python versions
- can manage projects
- can install projects
- can manage lock files
- etc.
- reads one data format (TOML, PEP 621) for all metadata
(That is why I’m fond of Rye, which, in spite of being “yet another tool”, is the first tool to date, AFAIK, to handle the “can install Python and manage Python versions” bullet.)
(And in contrast, there can be as many build backends as useful, though preferably one “canonical” build backend for pure-Python projects, e.g., hatchling.)
I think the “too many tools” mantra is well-accepted by now. What are your reasons to think that in an ideal world of packaging that we arrive at in 10 years, there are still different tools for scripts and for projects[1]? How does that allow better UX?
In a footnote, you write “And by the way, the priorities and trade-offs for managing environments for scripts are very different than those for managing project environments.”. Can you explain what you mean by that?
I’ve hesitated to write “scripts and projects” because I view the line between the two as blurrier than the PEP text. ↩︎