[Distutils] PEP 386 status - last round here ?

Tarek Ziadé ziade.tarek at gmail.com
Fri Nov 27 15:41:02 CET 2009

On Fri, Nov 27, 2009 at 3:31 PM, ssteinerX at gmail.com
<ssteinerx at gmail.com> wrote:
> On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:
>> On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> [..]
>>>> don't worry about Debian, we'll simply replace "-" with "~" (we use "~"
>>>> and "+" right now[0]). I'm not sure about rpm, but I bet it has
>>>> something similar and it will be much easier for us to simply handle two
>>>> characters instead of recognizing that dev1 < a1 < b1 < c1 == rc1 ...
>>> It's different from RPMs, since they use a strcmp(), segment  by segment,
>>> so I think they have to extract the dev/post suffixes and to put them in front
>>> as an epoch marker maybe ? (ccing Toshio)
>> That makes me think that a nice add-on to the lib and the PEP would be
>> to provide APIs to translate a Python PEP 386 version to a Debian/Ubuntu or RPM ones -
>> and any major packaging system out there. (whatever scheme we pick)
> Wouldn't it be cool if the package that goes along with this PEP became the standard version checker used by ALL of these distributions?
> It's not like they don't have Python interpreters around...

Piotr makes the point that every packaging system has already its
recipes and own tools, that are not Python-based for some of them. But
it doesn't hurt to provide something on our side too it I think.

> What would that API have to look like?  Maybe start a doc in the repo to hold that spec as we develop it?

The PEP 386 verlib API is ending in Distutils anyways, so third party
package managers will be able to
use verlib in their tools if they want.

So once the version scheme is decided, we can talk about extending the
lib to add more functions besides "suggest_rational_version". The
question will be to decide if it's stable enough to have it Distutils.

But that won't be a PEP discussion anymore, e.g. just candy on the top
of the version scheme.

> I'm still very interested in the increment_version functionality we talked about earlier so that we could have our build process automatically up our release version numbers so we have a standard way of maintaining incremental versioning.

That would be an interesting feature


More information about the Distutils-SIG mailing list