Awkward Versioning on PyPi

[mlavin]

The current version on django-tools on PyPi is 0.24.02.0710. That alone is not that odd. However once installed the version is shown as 0.24.02. This creates problem with trying to pin the version with a requirements file demonstrated below:

$ pip install django-tools
Downloading/unpacking django-tools
Downloading django-tools-0.24.2.0710.tar.gz (51Kb): 51Kb downloaded
...
Successfully installed django-tools
$ pip freeze | grep django-tools
django-tools==0.24.2

Now installing attempting to install this exact version errors:

$ pip install django-tools==0.24.2
Downloading/unpacking django-tools==0.24.2
Could not find a version that satisfies the requirement django-tools==0.24.2 (from versions: )
No distributions matching the version for django-tools==0.24.2

And trying to install the version including the date stamp works (pip install django-tools==0.24.2.0710) but fails if it is in a requirements file (That this works on the command line but not in a requirements file is noted in a pip bug: pypa/pip#145):

$ pip install -r dependencies.txt 
Downloading/unpacking django-tools==0.24.2.0710 (from -r dependencies.txt (line 20))
  Downloading django-tools-0.24.2.0710.tar.gz (51Kb): 51Kb downloaded
  Running setup.py egg_info for package django-tools
    warning: no files found matching 'README.textile'
    warning: no files found matching '*.css' under directory 'django_tools\templates'
    warning: no files found matching '*.js' under directory 'django_tools\templates'
    warning: no previously-included files matching '*.py[co]' found under directory '*'
  Source in c:\documents and settings\lavin\my documents\aptana studio workspace\origin\build\django-tools has the version 0.24.2, which does not match the
requirement django-tools==0.24.2.0710 (from -r dependencies.txt (line 20))
Source in c:\documents and settings\lavin\my documents\aptana studio workspace\origin\build\django-tools has version 0.24.2 that conflicts with django-tools==0.24.2.0710 (from -r dependencies.txt (line 20))

Removing the date stamp from the version number is probably the easiest solution but might not be desirable to you. In any case the version number should be constantly reported (always with the date or always without) to prevent this conflict error.

[jedie]

Thanks for reporting this.

I would like to leave the commiter date into the version string.

Now i have change the way that this date added to the version string, with: c72661d

I have made a simple filter for this, more info here: https://github.com/jedie/python-code-snippets/tree/master/CodeSnippets/git/

I hope that the reported issues is fixed with this. Please reopen and report if problems still exists...

[mlavin]

Thanks for the quick turn around!

[jedie]

btw. IMHO it's a better idea to add a range in your requirements file!

like:

django-tools>=0.24,<0.25

I do it in this way, see: https://github.com/jedie/PyLucid/blob/master/requirements/normal_installation.txt

[mlavin]

I'm going to disagree with you there. I think it's a better idea to pin your requirements to the exact version that you want so that no developers or environments are running different versions even if they are just "bug fix" differences. Packages are not consistent in how they version projects. Some make much larger changes when going from X.Y.Z to X.Y.Z+1. Even bug/security releases can introduce incompatible changes (either on purpose or by mistake).

In any case I came across this error because an coworker did

pip install django-tools
pip freeze > requirements.txt

and as noted doing pip install -r requirements.txt failed because freeze reported the version as 0.24.2 which doesn't exist on PyPi.

[jedie]

You where right, that version scheme are not consistent :(

But i do it like this: X.Y.Z to X.Y.Z+1 are not backward incompatible changed. incompatible is always: X.Y to X.Y+1

[jedie]

After playing with git filter and creating a commit hook i decided to remove the date form version string completely with v0.24.4

978ce5d