[Distutils] PEP 376 for Distutils

[Tarek Ziadé]

On Tue, Feb 24, 2009 at 12:13 AM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> Hello Tarek
>
> On Sun, Feb 22, 2009 at 03:37:50AM +0100, Tarek Ziadé wrote:
>> I have started a PEP for Distutils, I would like to work out for Pycon.
>>
>> http://svn.python.org/projects/peps/trunk/pep-0376.txt
>
> Looks quite nice so far IMHO.  Here some early feedback...
>
>
> """
> Back to our `zlib` example, we will have::
>
>    - zlib
>    - zlib-2.5.2-py2.6.egg-info/
>        PKG-INFO
>        MANIFEST
>        RECORD
> """
>
> What is the rationale for the `-2.5.2-py2.6' part in the name of the
> .egg-info directory?  I'm not saying I'm against it, rather that I'd
> like to see a rationale for why it is there and why it is different
> from the current distutils bit (doesn't add the python version, only
> package version).

If you look at install_egg_info, it will add the Python version

http://svn.python.org/projects/python/trunk/Lib/distutils/command/install_egg_info.py

I am not sure either this should be kept. I don't see the rationale
either, since
sys.version is known at runtime, it seems superfluous.

Maybe it should be deprecated.

I having the same problem with the version : since it is already
located in PKG-INFO,
there's no need to have it in the folder name;

So maybe the final version could be:

    - zlib
    - zlib.egg-info/
        PKG-INFO
        MANIFEST
        RECORD

>
> Related to this how is the behaviour of pkgutil.get_egg_info() defined
> in respect to this?  It mentions that all `pkg_name*.egg-info' files
> are looked for and None is returned if none is found.  But no word on
> what happens if more then one is found.  (Should that be an error?
> Guess it depends on the anser to the previous paragraph.)

In Distutils, there should be one egg-info per package. (While
setuptools multi-package
options allows to activate/deactivate various versions of the same package).

That said, I don't think this PEP should address multiple versions issues.

I'll add some details about this.

>
>
> """
> Let's use it over our `zlib` example::
>
>    >>> from pkgutil import get_egg_info, get_metadata,
>        get_egg_info_file
>    >>> get_egg_info('zlib')
>    '/opt/local/lib/python2.6/site-packages/zlib-2.5.2-py2.6.egg-info'
>    >>> metadata = get_metadata('zlib')
>    >>> metadata.version
>    '2.5.2'
>    >>> from distutils.dist import EGG_INFO_FILES
>    >>> get_metadata('zlib', EGG_INFO_FILES.manifest).read()
>    some
>    ...
>    files
> """
>
> I think there's a typo in the last call here.  Should that not be
> `get_egg_info_file('zlib', EGG_INFO_FILES.manifest).read()'?
>

right,

>
> Finally about the install and uninstall script.  Is this going to
> attempt to address the namespace packages problem or will this be left
> for a later PEP? AIUI if it doesn't (which seems reasonable,
> distutils never could do this) but setuptools does install such a
> package then distutils will happily try to remove it, using the
> .egg-info/RECORD file.  But this might then mess up any uninstall
> attempt from setuptools since a shared __init__.py might have been
> removed.

Right.  I think we can try to address namespace packages in another
PEP, because as far as I
can see, the namespace package boilerplate in setuptools is using
pkgutil.extend_path which
fixes __path__ variables on the fly. So I can't think of a case where
a static __init__.py file
will be shared, thus removed.


>
>
> Hope this was helpful in some way.

Thanks for the feedback Floris, I'll update the PEP accordingly

>
> Regards
> Floris
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/