2009/11/6 David Lyon <david.l...@preisshare.net>: [..] > Here are the references to the discussions from distutils-sig. In these > references you'll see that my interaction with the list was not grumpy > but was entirely positive. I feel that I got a fair hearing on distutils > list and I had a number of supporters to my proposal. > > The proposal is in the final stages of being wrapped up.
There are three different topics : 1. a standard for the installation format: PEP 376 2. changes in the metadata format : PEP 345 (-- work in progress here, some parts are still missing) 3. ways to built the metadata that are shipped into a distribution statically, using Distutils : PEP 390 was started for that And as a matter of fact, PEP 390 is not so important, because at the end, the changes that are made in PEP 345 are the most important ones. They allow describing metadata fields that can vary depending on the target platform. PEP 390 is just the simplest way to make it possible to describe static metadata using a setup.cfg ConfigParser section, rather than some code in setup.py. And when we built it, it helped us understand what we really wanted on PEP 345 side (with a big insights from people like Marc-André on this) But PEP 390 limits its scope to the Metadata fields and now waits for PEP 345 changes. Your proposal is a partial alternative to PEP 390, and is a quite interesting work to dig in, and the SIG is discussing it, but a very important point about it is that it does a lot more. It's a new *building* system on its own, and does not limit itself to describing metadata fields. That's fine, and that's quite interesting, but I doubt we will be able to push it in Distutils itself any sooner, because it a whole different system ala scons (which is a great tool don't get me wrong). I think (as I told you before IIRC) that you need to create a project to demonstrate it and I think it can be great to continue getting some help from Distutils-SIG for this. Furthermore, building such a tool on the top of Distutils can improve Distutils itself, because it would be yet another project that would provide valuable feedback on the APIs and standards we provide. That's for example what we are getting from projects like PyPM or Enthought Enstaller. As a matter of fact, there's already great feedback from Active State on PEP 376 because they want to be early adopters of the upcoming standard and make sure we do the right choices in there. Enthought also started to use the prototype we have written for PEP 386 (version comparisons) IIRC. But in the existing PEPs discussions, we need to focus on their respective scopes. And they are all targeted to improve the existing stdlib tool : Distutils. (and a wanted side effect is to make Distutils smaller if we can, and a robust basis for all third party tools) That's why you can't just drop a counter-PEP to any existing PEP we have started for Distutils. Imho help us build those PEPs, and / or create your own build system, wether its based or not on Distutils. Regards Tarek _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
