[Distutils] automating __version__' ing issues

[Phillip J. Eby]

At 09:14 PM 5/15/2007 +0100, Alexander Schmolck wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
>Will do. But wouldn't it make sense to be able to specify the version name in
>this place to?

Well, the version is a distribution level option; it can't be 
specified in setup.cfg.  That's a distutils thing, I'm afraid.

Btw, I erred in one point in my last email, your setup.cfg should 
actually read:

    [egg_info]
    tag_svn_revision = 1
    tag_build = .dev

Note the extra '.' - this ensures that if you have something like 
'1.1a' as your version, you won't end up with '1.1adev' as your version.


> > Where 'MyProjectname' is your setup(name=...) name.  (I.e., the 
> name of your
> > distribution.)
>
>Just to make sure because I'm not 100% clear on this and I think I have have
>come across conflicting information from different sources -- if my package is
>named scikits.mlabwrap and scikits is a namespace package, setup.py will have
>to look like so, right?
>
>     setup(name='sckits.mlabwrap',  # rather than just 'mlabwrap'
>           namespace_packages=['scikits']
>           ...
>     )

Uh, no.  Your distribution name could be "Matlab Wrapper for SciKits" 
or "FooBarBaz", for all the distutils or setuptools care.  :)

Project names don't have any defined relationship to package 
names.  For example the "Importing" project on the Cheeseshop 
provides a module called "peak.util.imports".



>and then ``require(scikits.mlabwrap)[0].version`` will get me the version
>number.

You need quotes around the scikits.mlabwrap...  or 'FooBarBaz', if 
that's your project name.  :)


>As a suggestion: I think that the ``namespace_packages`` example for the
>ZoperInterface project at
><http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages> would
>profit from adding the ``name=`` parameter, because it is not immediately
>obvious whether it should include the namespace_package or not.

It's entirely unrelated - note that a project can contain multiple 
packages, or even no packages at all.


>Thanks for all the info! I've tried to document the most important points
>about setuptools for other scikits developers, if you or someone else who's
>more knowledgable about setuptools wants to give some feedback (although it's
>obviously still work in progress), here's the url:
>
><http://projects.scipy.org/scipy/scikits/wiki/WikiStart#Scikitsuseofsetuptools>

Reading that page, I'm not sure whether you want a scikits namespace 
package in the first place. A namespace package is used to group 
several projects under a single "owner", ala the various zope.* and 
peak.* and plone.* packages.  However, nobody but Zope Corp. should 
be releasing a zope.* package, and nobody but me releasing a peak.* 
one.  The whole point is to "claim" a namespace for packages being 
released by a single owner - either an organization or umbrella 
project.  This corresponds to things like the 'org.apache' and 
'com.sun' package namespaces in Java - it's just a namespace to allow 
authors free rein to put whatever modules and packages they like 
under that namespace.

However, it sounds from that page like scikits are independently 
created - which means there's no need for a namespace package there, 
and in fact it's counter-indicated for that situation!

Also, may I suggest that rather than having a __version__ variable, 
why not just have a get_version() function?  That way, you needn't 
import pkg_resources or do a require() as part of a simple import operation.

Finally, it's not the case that you mustn't write a MANIFEST.in; 
setuptools will use MANIFEST.in just fine.  What setuptools *won't* 
do is rely on a generated MANIFEST for anything; it always uses a 
freshly-generated internal manifest, using MANIFEST.in + revision 
control info.  Thus, it's impossible to mess up setuptools with a 
stale MANIFEST file, the way you can with distutils.  (And if you're 
using CVS or SVN, you mostly won't need to bother with MANIFEST.in.)