Hi, I think we've reached a consensus on those two PEPs. Although, there's one last point that was forgotten in the discussions : I've introduced "rc" in the pre-releases markers, so PEP 386 is compatible with Python's own version scheme. "rc" comes right after "c" in the sorting. It's slightly redundant with the "c" marker but I don't think this really matters as long as consumers know how to order them (a < b < c < rc). I have also stated that "c" is the preferred marker for third party projects, from PEP 386 point of view. Is there anything else I can do to make those two PEPs accepted ? Regards Tarek -- Tarek Ziadé | http://ziade.org
Hi,
I think we've reached a consensus on those two PEPs.
Although, there's one last point that was forgotten in the discussions : I've introduced "rc" in the pre-releases markers, so PEP 386 is compatible with Python's own version scheme. "rc" comes right after "c" in the sorting. It's slightly redundant with the "c" marker but I don't think this really matters as long as consumers know how to order them (a < b < c < rc). I have also stated that "c" is the preferred marker for third party projects, from PEP 386 point of view.
Is there anything else I can do to make those two PEPs accepted ?
Tarek, Given that I helped out so much last year with the PEP in discussing different options, even if they weren't accepted, I really feel that it is unfair if my name isn't mentioned. It was a huge time sacrifice on my part. For example, even if I only managed to explain the version numbering and clarify how that worked. It did take me some time to do that. What I did do however, was spend a lot of time with the multiplatform "Markers". I still think that two short weeks more of "discussion" could resolve some issues. That discussion went for 4 months on distutils-ml. Look, major issues aside, can you make the following concessions on PEP-345 which I only feel will help it, namely: 1) Source-Repository: specify a code repository to install from 2) Streamline Requires-Python: by implementing "Markers" as noted by the PEP. A marker being something like "Requires-Python(windows): lxml". Otherwise remove the word marker from the PEP and just replace with "metacode". Markers are what were discussed on distutils-ml. Metacode is what is described in the PEP. 3) Remove the inconsistency and platform ambiguities. Especially for windows users. For example, "win32" is extremely confusing for windows users right now. As more and more systems now are 64 bit. Use the platform module, instead of the sys module for constants. I'll post to distutils-ml on this. I am certainly not trying to hold this PEP up, and I apologise on my part for my late attention. I will post to distutils-ml on these and i promise to keep my comments unheated and unwitty. Having said that, PEP-345 is *super-important*. A week or two or three more discussion and the issues can be resolved. We all just want to focus on being productive. It would be a great accomplishment for you to get PEP-345 approved and likewise for me getting mentioned even in a minor role as helping out on a PEP. So I'm hoping that you can make a few last minute concessions meaning that we can all happily go on our way in 2010. Regards David
On Tue, Jan 5, 2010 at 16:08, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Hi,
I think we've reached a consensus on those two PEPs.
Although, there's one last point that was forgotten in the discussions : I've introduced "rc" in the pre-releases markers, so PEP 386 is compatible with Python's own version scheme. "rc" comes right after "c" in the sorting. It's slightly redundant with the "c" marker but I don't think this really matters as long as consumers know how to order them (a < b < c < rc). I have also stated that "c" is the preferred marker for third party projects, from PEP 386 point of view.
Is there anything else I can do to make those two PEPs accepted ?
As you said, consensus has been reached, so just Guido's BDFL stamp of approval is all I can think of. -Brett
participants (3)
-
Brett Cannon
-
David Lyon
-
Tarek Ziadé