[Distutils] PEP 386

[Tarek Ziadé]

On Tue, Oct 20, 2009 at 2:56 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Tarek Ziadé wrote:
>>
>> On Tue, Oct 20, 2009 at 2:30 PM, Chris Withers <chris at simplistix.co.uk>
>> wrote:
>>>
>>> Tarek Ziadé wrote:
>>>>
>>>> Then, the day PEP 386 is accepted, we turn "python_version" into a
>>>> Version()
>>>> object and we introduce '>', '<' and al.
>>>
>>> What's stopping PEP 386 being accepted?
>>> Seems like it'd be a good idea to get it out of the way first...
>>
>> The last round (last summer) was not in favor of having post/dev
>> markers in the version scheme
>> (these are required by some developers), so PEP 345 and PEP 386 where
>> sleeping a bit.
>
> I'm sure I can't be the only person suffering from PEP overload when it
> comes to packaging.
> Any chance we could at least get dev/post markers in
> PEP386 and get it done and out of the way?
>
> I have a feeling that PEP345 and PEP390 along with David's alternative
> proposal are all related in such a way that the best thing ot do is bottom
> out the latter two first, but they all seem to depend (whether or not they
> want to admit it ;-) ) on PEP 386...
>

Agreed. And every piece of puzzle is starting to emerge.

As Marc-André said, PEP 390 is less important and could be done in
distutils even without PEP,
as long as we add the markers in PEP 345, (meaning we accept 386).

And while David's alternative proposal competes with PEP 390 I don't
see that as a problem:
PEP 390 proposes to build the metadata using options in setup.cfg,
whereas David's proposal
proposes another system, but at the end, they all end up in a PKG-INFO.

Tarek