Should PEP 704 be a PEP?

[pradyunsg (Pradyun Gedam)]

@steve.dower

So it feels like it’s solely motivated to get PEP 582 rejected by using process. Which is not an uncommon thing for us to do, and it’s legitimate approach, but as 582 is clearly standards track and this is pretty obviously not (despite the metadata claiming so), I doubt it’ll work.

That’s not the goal for me, at least. I view this as an alternative approach to solving the UX problem, wherein we lean further into the venv-based model for the ecosystem rather than adding an alternative place for putting installed packages.

I’ve explicitly stated that I see arguments both ways for PEP 582 and PEP 704 when I first mentioned that I’ve written it, and I also don’t think it’s as simple as we’d do one or the other (status quo is certainly an option).

@njs

But even if this PEP is supporting a change that’s good, I can’t really support a process that’s ultimately based on harassment as a way to get there.

Being accused of harrasing (or strong-arming through process) was not something I expected TBH, and y’all are reading this situation in ways that I do not understand.

I’m happy to withdraw the PEP 704, if people think using PEPs for discussing design choices that fundamentally affect the language’s packaging experience and serves as a direct alternative to another Packaging PEP is not something that is worthy of a Packaging PEP.

I really don’t know what is PEP-worthy at that point, and would like each of you to explicitly state both:

• why you think this isn’t a PEP-worthy topic and
• what format you would’ve prefered this proposal to take.