Python PEP 440 and RPM Versions

[Simo Sorce]

I have been searching the web to see if we have any hard and fast rule
on converting the PEP 440 version names into an RPM NVR that will allow
correct upgrades when a Python package is released.

In particular in PEP 440 the following ordering is true:

0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 <
0.2.post1

I haven't found any Fedora Packaging rules or otherwise any
recommendation on transforming a PEP440 package version number to an RPM
NVR.

The first thing that comes to mind is that the above numbers become r
respectively:

0.2.dev1 -> name-0.2.0-0.0.dev1
0.2.a1   -> name-0.2.0-0.1.alpha1
0.2.b1   -> name-0.2.0-0.2.beta1
0.2.rc1  -> name-0.2.0-0.3.rc1
0.2.c1   -> name-0.2.0-0.3.rc1 (yes c -> rc here)
0.2      -> name-0.2.0-1
0.2.0    -> name-0.2.0-1
0.2.post1 -> name-0.2.0-1.post1

if any of the packages need bugfixes they would have to append a release
number, ie a patch on post1 would result in name-0.2.0-1.post1.1

Does this make sense ?
Should it be written down/agreed/discussed anywhere/somewhere else ? 

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Jason L Tibbitts III]

> >>>> "SS" == Simo Sorce <simo(a)redhat.com&gt;
> writes: 
SS> I haven't found any Fedora Packaging rules or otherwise any
SS> recommendation on transforming a PEP440 package version number to an
SS> RPM NVR.

Don't the existing versioning guidelines already cover this, though?  I
don't see how they fail to do so.

https://fedoraproject.org/wiki/Packaging:Versioning#Non-Numeric_Version_i...

Isn't that pretty much what you describe?  (Except that in the very last
case should be name-0.2.0-2.post1 because the release integer must
always increment.)

 - J<

[Simo Sorce]

On Tue, 2016-08-23 at 14:35 -0500, Jason L Tibbitts III wrote:
>  >>>>> "SS" == Simo Sorce
> <simo(a)redhat.com&gt; writes:
>  
>  SS> I haven't found any Fedora Packaging rules or otherwise any
>  SS> recommendation on transforming a PEP440 package version number to an
>  SS> RPM NVR.
>  
>  Don't the existing versioning guidelines already cover this, though?  I
>  don't see how they fail to do so.
>  
>  https://fedoraproject.org/wiki/Packaging:Versioning#Non-Numeric_Version_i...
>  
>  Isn't that pretty much what you describe?  (Except that in the very last
>  case should be name-0.2.0-2.post1 because the release integer must
>  always increment.) 
I was looking for something specific to PEP 440
equivalence/normalization rules, I guess there aren't and there is no
interest in being overly prescriptive for this case ?

The common rules do allow me to create packages that will update
properly though, and I can certainly figure out my way in the ambiguous
cases, so they suffice for the time being.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Jason L Tibbitts III]

> >>>> "SS" == Simo Sorce <simo(a)redhat.com&gt;
> writes: 
SS> I was looking for something specific to PEP 440
SS> equivalence/normalization rules, I guess there aren't and there is
SS> no interest in being overly prescriptive for this case ?

I'm not sure.  I mean, if someone wants to write something I don't see
how it would hurt, but I'm not sure it wouldn't just repeat what's
already there.  Maybe just using the python thing as another specific
example?

 - J<

[Neal Gompa]

On Tue, Aug 23, 2016 at 3:25 PM, Simo Sorce <simo(a)redhat.com&gt; wrote:
>  I have been searching the web to see if we have any hard and fast
> rule
>  on converting the PEP 440 version names into an RPM NVR that will allow
>  correct upgrades when a Python package is released.
>
>  In particular in PEP 440 the following ordering is true:
>
>  0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 <
>  0.2.post1
>  
If we were allowed to, I'd probably structure like so in the Version field:

0.2~0.dev1 < 0.2~a1 < 0.2~b1 < (0.2~rc1 | 0.2~c1) < ( 0.2 | 0.2.0 ) <
0.2+post1

To me, this is more natural than doing the weird release hacking we do now.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Neal Gompa]

On Tue, Aug 23, 2016 at 4:11 PM, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Aug 23, 2016 at 3:25 PM, Simo Sorce <simo(a)redhat.com&gt;
> wrote:
> > I have been searching the web to see if we have any hard and fast rule
> > on converting the PEP 440 version names into an RPM NVR that will allow
> > correct upgrades when a Python package is released.
> >
> > In particular in PEP 440 the following ordering is true:
> >
> > 0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 <
> > 0.2.post1
> >
>
>  If we were allowed to, I'd probably structure like so in the Version field:
>
>  0.2~0.dev1 < 0.2~a1 < 0.2~b1 < (0.2~rc1 | 0.2~c1) < ( 0.2 | 0.2.0 ) <
> 0.2+post1
>
>  To me, this is more natural than doing the weird release hacking we do now.
>  
I'd also like to note that this also rather cleanly handles structures
like the following:

0.2.dev1+post2 => 0.2~0.dev1+post2

This scheme is possible in all Fedora versions and at least in EL6 and up.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jason L Tibbitts III]

> >>>> "NG" == Neal Gompa
> <ngompa13(a)gmail.com&gt; writes: 
NG> 0.2~0.dev1 < 0.2~a1 < 0.2~b1 < (0.2~rc1 | 0.2~c1) < ( 0.2 | 0.2.0 )
NG> < 0.2+post1

We've been over the terrible tilde magic thing already (more than once).
It doesn't solve the general problem and hence only adds complexity
instead of helping.

 - J<

[John Dennis]

On 08/23/2016 03:25 PM, Simo Sorce wrote:
>  I have been searching the web to see if we have any hard and fast
> rule
>  on converting the PEP 440 version names into an RPM NVR that will allow
>  correct upgrades when a Python package is released.
>
>  In particular in PEP 440 the following ordering is true:
>
>  0.2.dev1 < 0.2.a1 < 0.0.b1 < 0.2.rc1 == 0.2.c1 < 0.2 == 0.2.0 <
>  0.2.post1
>
>  I haven't found any Fedora Packaging rules or otherwise any
>  recommendation on transforming a PEP440 package version number to an RPM
>  NVR.
>
>  The first thing that comes to mind is that the above numbers become r
>  respectively:
>
>  0.2.dev1 -> name-0.2.0-0.0.dev1
>  0.2.a1   -> name-0.2.0-0.1.alpha1
>  0.2.b1   -> name-0.2.0-0.2.beta1
>  0.2.rc1  -> name-0.2.0-0.3.rc1
>  0.2.c1   -> name-0.2.0-0.3.rc1 (yes c -> rc here)
>  0.2      -> name-0.2.0-1
>  0.2.0    -> name-0.2.0-1
>  0.2.post1 -> name-0.2.0-1.post1
>
>  if any of the packages need bugfixes they would have to append a release
>  number, ie a patch on post1 would result in name-0.2.0-1.post1.1
>
>  Does this make sense ?
>  Should it be written down/agreed/discussed anywhere/somewhere else ? 
Isn't this covered by PEP 440 Local Version scheme?

https://www.python.org/dev/peps/pep-0440/#id23


-- 
John