pytz version number (2013b) is considered a pre-release by pip 1.4

[Grzegorz Śliwiński]

I'm dealing with issue, where pytz version numbering (2013b at the moment of writing), is causing pip to fail package to install)

So, trying to simply install pytz, is giving this:

pip install pytz
Downloading/unpacking pytz
  Could not find a version that satisfies the requirement pytz (from versions: 2009r, 2008b, 2009f, 2008c, 2007g, 2011g, 2005m, 2011e, 2007f, 2011k, 2007k, 2006j, 2008h, 2008i, 2011e, 2008a, 2009e, 2006g, 2011j, 2010l, 2005m, 2008i, 2005k, 2008g, 2007c, 2007i, 2009l, 2009r, 2006j, 2011k, 2007d, 2006p, 2009i, 2009u, 2007i, 2009f, 2010g, 2008h, 2009a, 2007g, 2011e, 2006p, 2012b, 2010k, 2005r, 2007f, 2009l, 2009p, 2008c, 2009j, 2008g, 2010g, 2010h, 2011h, 2010k, 2007c, 2007d, 2011d, 2009l, 2011c, 2008a, 2005m, 2007k, 2009n, 2011d, 2010o, 2013b, 2012h, 2010e, 2012c, 2012d, 2012f, 2011n, 2011b, 2011j, 2008c, 2012j, 2007k, 2009f, 2009d, 2010e, 2010b, 2013b, 2011d, 2009p, 2008h, 2005r, 2009i, 2009n, 2009a, 2010k, 2008g, 2006g, 2008b, 2012c, 2009i, 2007g, 2012c, 2010h, 2011n, 2012g, 2007d, 2008a, 2009u, 2012g, 2010o, 2006p, 2010b, 2009u, 2012d, 2011k, 2012f, 2009a, 2007f, 2011h, 2010l, 2009j, 2011g, 2009g, 2009g, 2005r, 2011c, 2012g, 2009g, 2012d, 2009j, 2010o, 2007c, 2010g, 2006g, 2009d, 2010h, 2005k, 2006j, 2010b, 2009n, 2011g, 2011c, 2012b, 2009e, 2009d, 2011j, 2007i, 2012j, 2010l, 2009r, 2012h, 2010e, 2009p, 2008i, 2012f, 2009e, 2012b, 2011h, 2005k, 2008b, 2011n, 2012j, 2013b, 2004b)
Cleaning up...
No distributions matching the version for pytz
Storing complete log in /home/fizyk/.pip/pip.log

I can of course install with exact version number pip install 'pytz==2013b', which works fine, but usually I have a list o requirements, that are delivered in a text file, and during install, or updating packages, if one of my requrements, requires pytz, I'm in trouble.

I could install it with easy_install, which does not respect prereleases, but that would be a little bit dangerous, and also easy_install is being deprecated in favour of pip.

Please, consider adopting pep386: http://www.python.org/dev/peps/pep-0386/ numbering version. Even if it means we'll have new version scheme since 2014, that would be much appreciated. Especially, that people usually just install packages through pip, noit using buildout, or other tools.

Also, it might be more complicated, but nevertheless more helpful, since 20014, you could release pytz twice, once with current schema, second with new pep386 compatible one.

Issue has been brought to us, by pip 1.4: http://www.pip-installer.org/en/latest/news.html#id1

[Tomasz Karbownicki (tomasz-karbownicki)]

Same problem here, +1.

[Donald Stufft (dstufft)]

FWIW you can solve this in a backward compat way by doing something like..

2013a -> 0.2013.01
2013b -> 0.2013.02

Or

2013a -> 13.1
2013b -> 13.2

While simultaneously releasing the same thing under the original versioning scheme. The one place this would fall down is if someone installs a "pre-release" of 2013a, but then attempts to only install "stable" after that. The "stable" versions will always appear to be less than the "pre-release" versions so people would need to be consistent in how they tried to install it.

[Alex Gaynor (alex-gaynor)]

I think moving to 2013.1, 2013.2, etc. is the most consistent and sane thing to do.

[Armin Ronacher (mitsuhiko)]

The pytz version number is currently in sync with the zone database number. People have been using the pytz.__version__ attribute for a while to see which version it corresponds to. I believe that if the version numbering is changed then a second version attribute should be added to pytz that identifies the version of the timezone database that it is based on.

[Stuart Bishop (stub)]

There has been discussion on this issue at https://github.com/pypa/pip/issues/974

[Donald Stufft (dstufft)]

Hm, so techincally 2013.1 would work. However the issue there is that's techincally an invalid version number as per PEP440 at the moment (date based releases are explicitly excluded from the public version number [1][2]. So I don't know that you'd be guarenteed going forward that pip (or possibly another tool) will continue to see it as a stable release in the future.

Essentially the argument for explicitly disallowing date based releases was that it makes it impossible to migrate to the preferred scheme of not-date based. I'm not going to argue the relative merits of date based or not here (there's distutils-sig for that!). Just an FYI that if you use 2013.1 there's a possibility for future breakage.

[1] http://www.python.org/dev/peps/pep-0440/#final-releases
[2] http://www.python.org/dev/peps/pep-0440/#date-based-versions

[Donald Stufft (dstufft)]

PEP440 is going to be updated to allow 2013.1, 2013.2, etc.

So it makes sense to switch to using a versioning scheme like this that just translates the letter to a number.