[Distutils] DRAFT PEP 396 - module version number

[P.J. Eby]

At 10:31 AM 4/5/2011 -0400, Barry Warsaw wrote:
>On Mar 25, 2011, at 03:52 AM, Éric Araujo wrote:
> >I am not sure we should advertise setuptools namespace packages, given
> >that standardization is under way (PEP 382).  On one hand it would be
> >childish not to acknowledge that setuptools is widely used, on the other
> >hand in this particular time and place I think we should wait for
> >official namespace packages to be implemented and talk about those.

Just as an FYI, "official" namespace packages have existed since 
Python 2.3; they are implemented using pkgutil.extend_path() -- 
added, IIRC, back when Guido and Barry were both working at Zope Corp.  ;-)

Setuptools and PEP 382 are simply enhanced implementations of the concept.


> >> #. For modules which live inside a namespace package, the sub-package
> >>    name SHOULD include the ``__version__`` attribute.
> >I think this works with both setuptools and PEP 382 namespace packages,
> >which is nice (see above questioning).
> >
> >> The namespace module itself SHOULD NOT include its own
> >> ``__version__`` attribute.
> >I guess this makes sense for setuptools namespace packages, but from my
> >understanding of PEP 382, it is possible to have a Python package that
> >is a namespace package and has submodules.  (I hope Martin will correct
> >me if needed.)  This thing (“portion” in PEP 382 lingo) should be
> >allowed to declare a version IMO.
>
>Agreed, if that is true.  I kind of hope it's *not* true though!  Anyway, this
>is a SHOULD NOT not MUST NOT so I think it's safe.

In principle, if you simply *must* have a non-empty __init__ module 
in a namespace package, and you really need to have a __version__ of 
that, then I suppose its __version__ should match the version of the 
project that supplies it.

But yeah, I think it should still be considered a poor practice to 
put stuff in a namespace's __init__, even if/when PEP 382 makes it 
practical to implement non-empty __init__'s.