I’m catching up on PEP 722: Dependency specification for single-file scripts - #223 after being away for a few days, but basically my main thought is that I still don’t think this PEP is a good idea. It’s clear from this thread that there is substantial disagreement about fundamental questions. The PEP has come down on one side or the other and that is fine as a proposal, but in that situation I think the right thing to do is reject it until we can more fully work through all the concerns raised and their connections to related packaging issues (such as the “pyproject.toml for non-wheels” thing).
I do want to say one more thing in light of the packaging survey results that were discussed earlier. This may sound a bit negative so please anyone who reads it just try to take it in the spirit of those other threads on “doing what is best for Python packaging”. And it’s all, just, like, my opinion, man.
In my view, the process and discussion in this thread illustrates some of the causes of the problems identified in the survey. Basically the situation is that there is a use case, and someone writes a PEP with a particular approach to that use case. There is then a relatively quick process by which that particular proposal is evaluated. If that PEP is accepted, it then is perceived to be laying down the law for how that use case is to be handled. Tools that do not want to handle that use case in that way then tend to diverge to varying degrees; this often happens because tools are designed to meet a range of needs and sometimes the PEP-official way doesn’t fit well with other things the tools are trying to do.
The end result is that a PEP designed to address a particular use case impacts all future attempts by all tools to address that use case (whether they choose to follow that PEP’s mechanism or not), as well as tools that may not care about that use case but still have to avoid stepping on the PEP’s toes (e.g., for the present PEP any tool that may use or want to use structured comments for anything else).
Having seen a few PEP discussions on this forum, my impression is that a fair number (especially “small” ones like this that are perceived as filling in narrow gaps in existing tools and standards) are approved more quickly than they perhaps ought to be, and I’m a bit worried that that will again happen here.
What I think the packaging survey showed is that people want everything to work smoothly together. To me that means that looking at a seemingly simple proposal like this PEP and approving or denying it “on its own merits” in terms of how it addresses the intended use case is not really sufficient. There needs to be a slower process of examining all the tie-ins of the proposal to other questions about Python packaging to determine if the total state of the packaging world after the PEP will be better — including whether it will be easier to move towards the “grand unified future” discussed in some of the other threads where we do have everything working together smoothly.
So, for instance, with this PEP, we have the question of whether it should use TOML or some other format, and part of the reason is to tie in (or not) with pyproject.toml, and there is discussion on another thread about how to use (or not use) pyproject.toml for “projects” (whatever that may mean ) that don’t build a wheel, and as far as I can tell that discussion has not reached any consensus, and meanwhile this PEP is proposing a mechanism for specifying dependencies for a “project” (broadly construed, in this case just a single file) but not intending to generate a wheel. There is a complex interconnection there with doubt at several points. That right there is enough for me personally to conclude “the right thing to do right now is nothing”. We should wait until we have a better understanding of those related questions and how they relate, in order to make sure a chosen solution to one fits well with chosen solutions for others. To do otherwise risks creating more awkward seams in the packaging world.
I think this situation comes up a lot in various decision-making processes, not just Python and its PEPs. My little motto here is: “Every decision should be about everything.” That is, every decision has to be sure to take full account of other decisions being made in parallel and (as much as possible) future decisions that will branch out from it. (Of course, I realize not everyone agrees with me on this. )
I don’t mean by any of this to suggest that the many contributors far wiser and more experienced than me are suffering from hopeless tunnel vision or anything like that. I’m sure all involved are aware that this decision will fit into a larger ecosystem. All I’m saying is that right now my perception is such concerns aren’t playing as big a role in the overt discussion and progress of the proposal as maybe they ought to, and maybe things are getting a bit rushed.