Comment 9 for bug 531662

On Tue, Apr 13, 2010 at 7:49 PM, Tres Seaver <email address hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jim Fulton wrote:
>> On Tue, Apr 13, 2010 at 5:10 PM, Tres Seaver <email address hidden> wrote:
>>> AFAIK, we have 3 places to put the version number without duplication:
>>>
>>>  - in setup.py (where it has to be passed to setup().  pkg_resources consumes
>>>   this value indirectly through the PKG-INFO file generated during installation.
>>>
>>>  - in an attribute of a module (which one, please?  Defend your choice.
>>> ;)
>>>
>>>  - In a data file in the package (something like the Zope2 product convention of
>>>   'version.txt').
>>
>> I would put it in a text file in the package.  I would have the
>> __init__ of the package load this into the __version__ attribute for
>> instrospection by run-time code.
>
> I don't think there is any reliable way to read such a file at import
> time that doesn't depend on pkg_resources (think zipped trees on GAI, or
> zipped eggs, etc.).

Good point.

Hm, so you zip your packages to make them fit on GAI,
now you have 2 problems. :)

I guess the file could be a .py file, which would rather suck.

>
>> (AFAIK, __version__ is still a Python standard.)
>
> Hmm, I wouldn't reead PEP8 that way:
>
>  Version Bookkeeping
>
>    If you have to have Subversion, CVS, or RCS crud in your source
>    file, do it as follows.
>
>        __version__ = "$Revision: 68852 $"
>        # $Source$
>
>    These lines should be included after the module's docstring,
>    before any other code, separated by a blank line above and below.
>
> That sounds pretty disparaging to me.  Not only that, it says *nothing*
> about a "release ID", which is wildly different from a VCS revision ID
> for a specific file.

Well, I was in the room at SPAM I when the feature was proposed and
the intent was to capture the "module" version. This wasn't ties to
source control. Source control provides
a convenient mechanism for individual files.

...

> I'm unhappy about coding up any non-standard support for such a feature.

Me neither.

>  Given that pkg_resources works in nearly any environment where our
> packages are used today, I can' t see any win for adding workaround
> cruft to our packages just to avoid it.  In other words, I would rather
> not support the feature at all than add code which supports it badly,
> and differently in each of the dozens of packages we already support.

I really really really wish distribute or setuptools or something suitably
like them would become truly standard. Until that day, life will suck. :)

>> I don't feel strongly about this, but would be inclined to try to do
>> something simple.
>
> I guess I am -0 on doing anything at all, especially in the absence of
> any concrete use cases for using such a feature in environments where
> setuptools / pkg_resources is not already ubiquitous.

That's fine. I may try something anyway, if only because this
keeps coming up and I find the answer of requiring setuptools
to be pretty unsatisfying. Yeah -- I realize that most of our packages
require setuptools to be installed ....

Jim

--
Jim Fulton