[Distutils] Specifying version information once

[Jean-Paul Calderone]

On Wed, 20 May 2009 10:17:31 +1000, Ben Finney <ben+python at benfinney.id.au> wrote:
>Jean-Paul Calderone <exarkun at divmod.com> writes:
>
>> For a long time, the idiom I've used to specify version information in my
>> distutils-based packages has been this simple one: put version information
>> into the Python package somewhere, structure the source layout so that the
>> package can be imported directly from an unpacked source tarball (or vcs wc),
>> and import the version into setup.py.  This worked great.  And I only had to
>> define my version once.
>>
>> Increasingly, it seems that new distutils-related tools don't support this
>> idiom and break in various ways.  (eg
>>
>>  http://divmod.org/trac/ticket/2629
>>  http://divmod.org/trac/ticket/2831
>> )
>
>Those breakages seem to be caused in part because the module containing
>version information is doing too much.

The only thing the version module does is define the version.  For example,

  $ cat _version.py
  # This is an auto-generated file. Use Epsilon/bin/release-divmod to update.
  from twisted.python import versions
  version = versions.Version(__name__[:__name__.rfind('.')], 0, 9, 33)
  $

Of course, the "too much" here is the use of a structured version object.
Doing anything simpler would be much like the approach Phillip's pointed
out, to have a simple text file and parse its contents without getting
Python involved at all.

>
>> What is the recommendation for specifying version information in a way
>> which is compatible with all these new tools?
>
>I would recommend having a module in your package whose *only*
>responsibility is version information for the package, so that importing
>it won't break in different environments.
>
>That module can the be imported both by the package itself when it needs
>to know its version string, and by the ‘setup.py’ to get that same
>version string for package building.

This has issues.  For examples, sometimes a system-wide installation of the
package will get used instead (generally not when running setup.py directly,
but it seems to happen when other tools are used).  Otherwise, the existing
_version.py from above works fine.

Jean-Paul