On 7/13/15, 16:19, "Joshua Harlow" <[email protected]> wrote:
>Ian Cordasco wrote: >> >> On 7/13/15, 15:09, "Dave Walker"<[email protected]> wrote: >> >>> On 13 Jul 2015 8:52 pm, "Ian Cordasco"<[email protected]> >>>wrote: >>>> On 7/13/15, 03:38, "Thierry Carrez"<[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
