Open Stack

On 7/13/15, 16:19, "Joshua Harlow" <harlowja at outlook.com> wrote:

>Ian Cordasco wrote:
>>
>> On 7/13/15, 15:09, "Dave Walker"<email at daviey.com>  wrote:
>>
>>> On 13 Jul 2015 8:52 pm, "Ian Cordasco"<ian.cordasco at rackspace.com>
>>>wrote:
>>>> On 7/13/15, 03:38, "Thierry Carrez"<thierry at openstack.org>  wrote:
>>> <SNIP>
>>>>> By "counter-productive", I meant: likely to generate more confusion
>>>> than
>>>>> clarity. If you provide an epoch in the version and it doesn't match
>>>>> downstream packagers ones, it's hard to rely on it.
>>>> I see what you mean now. The thing is that for Debian/Fedora the epoch
>>>> syntax is different from PEP 440
>>>>
>>>> For them it's
>>>>
>>>> [distro-epoch]:[upstream-version][otherstuff]
>>>>
>>>> PEP 440 epochs are separated by a !, so let's say $(distro) has an
>>>>epoch
>>>> value of "1" and we choose "2", for glance the version would look ugly
>>>> but
>>>> would be:
>>>>
>>>> 1:2!11.0.0
>>>>
>>> <SNIP>
>>> This would be a problem for at least Ubuntu and Debian as the version
>>> string is specifically not allowed to contain a '!'.
>>> "The upstream_version may contain only alphanumerics and the
>>>characters .
>>> +- : ~ (full stop, plus, hyphen, colon, tilde) and should start with a
>>> digit." [0]
>>
>> Thanks for the input Dave. I didn't see that part since I was
>>specifically
>> looking for how epochs are denoted. I still am quite certain that we
>>have
>> no choice but to use the proper versioning tools upstream though and
>>that
>> means using ! to indicate the epoch in our version strings because these
>> are fundamentally Python packages.
>
>+1 we produce python versions, and people use them (whether they are
>uploaded to pypi or not) so we should try to do the right thing here no
>matter what. If downstream distro (rh, ubuntu, other...) wants to
>convert that into its local epoch scheme that's cool (and I would expect
>them to do that in the correct manner that is appropriate for there
>packages).

Since the mailing list reaches the largest number of people, I thought I'd
continue some of this discussion here.

Yesterday some further discussion happened in #openstack-infra (on IRC),
and the crux of the argument against Epochs seems to be that they make it
hard to deal with archives on the command line, e.g., you'd have an
archive generated that looks like:

    nova-1!12.0.0.tar.gz

Perhaps I'm misunderstanding, but any relatively modern shell that allows
for tab completion will properly tab-complete that when using the filename.

Another argument is that this is something ugly that we'll have to live
with for the rest of OpenStack's life. Without it, however, we'll have to
live with 12.0.0 < (the last four years of version numbers) as a sorting
mechanism as far as Python packaging is concerned.

There's also the argument that (paraphrasing) this isn't really a problem
for people using pip because you can do `pip install -U nova==12.0.0` once
and you're done. Except that if you have a local package index and you're
support reproducible builds of multiple versions, say, Juno (2014.2.x),
Kilo (2015.1.y), Liberty (your version number depends on project but is
strictly less than both Juno and Kilo), and M. If you upgrade a project
from Liberty to M, you have to still use `pip install -U nova==13.0.0`
because `pip install -U nova` will install Kilo because neither Liberty
nor M are using an epoch. We're effectively saying "if you support more
than one release at a time using the python packaging ecosystem, you're a
second class citizen in OpenStack".

In other words, this will be an ongoing problem. Epochs are clearly a
necessity, otherwise our downstream distributors wouldn't be using them
and the PEP 440 authors wouldn't have included them. Epochs were designed
exactly for this situation, and while they're ugly, they're the absolutely
correct approach here.

As a sidenote, in case people are wondering how epochs even work with pip,
2015.1.0 has an implicit epoch of 0, e.g., the version can be equivalently
written as 0!2015.1.0. 1!12.0.0 would sort higher because 1 has a higher
value than the implicit 0. 1!13.0.0 then defers to the rest of the version
string because they belong to the same epoch.

Cheers,
Ian