With all respect for Brett, how is it that someone with an explicit stake in this through their employer (and who knows what other related constraints about product delivery, timing, etc.) can become the PEP delegate on this?
The SC has rules to prevent over-representation to any one company, and now we’re asking one person with a definite stake in the outcome (rather than a more neutral party) to make this decision for the rest of the Python world at large?
I really mean no disrespect to @brettcannon here, but this kind of process failure is a concern to me. Unfortunately we don’t have a PyPA council yet, but I find it hard to believe that there could not be a similarly knowledgeable yet more neutral decision maker (or perhaps defer the PEP to the SC directly).
I might not have commented on this under other circumstances, but I find this kind of attitude concerning. This sounds a lot like “Be glad I’m even considering an alternative and giving you a week to write it”, and if so, I would very much not be glad.
How is it that this use case, that has not been covered for years, suddenly needs to be solved now, with a forced choice between PEP722 and whatever alternative will “generously” be considered? Rather than taking some more time for designing this coherently and not adding to the pile of things in python packaging that are bolted on?
Is it because VS Code would like to have a certain feature with an official stamp of approval? Probably not, and it’s just that @pfmoore asked Brett to fill in since he cannot approve his own PEP.
But outside of a handful of people, we cannot know that, and forcing a quick decision here does not improve the optics. From a wider POV (e.g. users asking us to unify things), this rush makes no sense to me, and IMO it’s harmful to the packaging ecosystem (basically a big +1 to @BrenBarn’s post that got separated into its own thread, as well as some of @jeanas thoughtful points on the long term view).
Please consider recusing yourself @brettcanon.