On September 5, 2015 at 7:13:18 PM, Nick Coghlan (ncog...@gmail.com) wrote:
> On 6 Sep 2015 08:31, "Marcus Smith" wrote:> >> > is this a response to other thread about how/where to store specs and> PEPs?> > If not, what in this email are you responding to?> > I believe Donald was suggesting we could just have a PyPA specific change> proposal process hosted on packaging.python.org, rather than using a> variant of the PEP process.> > I don't want to do that though - PyPA/distutils-sig's authority *is*> delegated from python-dev through the BDFL-Delegate and Discussions-To> headers in the regular PEP process, and there are going to be some> proposals affecting ensurepip and distutils that still fall under> python-dev rather than distutils-sig.> > Dealing with the PEP repo is currently more painful than it needs to be,> but that's what the forge.python.org proposals aim to address.>
I was yes, though I don't feel extremely strongly about it, but I do wonder if
it wouldn't fit us better. I'll make my case here real quick, but unless others
are interested in it I don't really feel strong enough to push for it.
We're currently using the PEP process, but we've had to bend the PEP rules
several times in order to fit us. It's obvious the PEP process is designed
primarily to handle changes to Python itself, even the BDFL-Delegate rules
currently state you have to be a Python core developer and that you need
permission from Guido for it. On top of that, almost all of the things we touch
don't really fall under python-dev's authority. PyPI, pip, setuptools,
bandersnatch, devpi, etc are external projects and only really distutils and
ensurepip need python-dev's stamp of approval. In a way, we're already part way
to the RFC process that rust uses through the interoperability-peps repo on
Github. The primary differences would be that we manually copy things over to
the Python PEPs repository and we don't really follow the rules for
BDFL-Delegates, we just invent our own rules and it's sort of OK because nobody
It is kind of awkward to essentially have the "real" copy of the PEP live in
Github and that's where all the work on it happens but then needing to manually
copy things over. It makes it kind of annoying to work on things, especially
since any typo change or the such requires additional work to keep the two
copies in sync.
On the other hand, if we focused on a process that worked for us, instead of
trying to shoe horn things into the PEP process we could optimize it for how
we function. This could also include direct integration with
packaging.python.org or something similar if we wanted to go down that road.
I don't know, I think we could have a better process if we did our own thing,
so it's something to think about at least.
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Distutils-SIG maillist - Dist...@python.org