[Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

[M.-A. Lemburg]

I have just a few comments to make, so I'm trimming the long quote
a bit...

> Tarek Ziadé a écrit :
>> == Version comparison ==
>>
>> One very important point: we will not force the community to use the
>> scheme described in PEP 386, but *there is* already a
>> de-facto convention on version schemes at PyPI if you use Pip or
>> easy_install, so let's have a documented standard for this,
>> and a reference implementation in Distutils.
>>
>> There's an implementation at
>> http://bitbucket.org/tarek/distutilsversion that is kept up-to-date
>> with PEP 386.
>>
>> - Work left to do in PEP 386 : another round with the community
>> - Goal: 2.7 / 3.2

Please make sure that the version scheme is compatible with
other tools we use in the distutils chain: RPM and the MSI
compiler.

Some data points: RPM doesn't like hyphens in version strings.
MSI requires a strict N.N.N format.

>> == The fate of setup.py, and static metadata ==
>>
>> So we are going to separate the metadata description from setup.py, in
>> a static configuration file, that can be open and read by anyone
>> without
>> running any code. The only problem with this is the fact that some
>> metadata fields might depend on the execution environment. For
>> instance, once "Requires" is re-defined and re-introduced via PEP 314,
>> we will have cases where "pywin32" will be a dependency to have only
>> on win32 systems.

How are you planning to deal with dynamic version strings, e.g.
say you want to build a snapshot release the current date and
revision number included in the version string ?

I suppose this file is going to be uploaded to PyPI, so the
file would have to be formatted at build time and include
markers to be replaced with values taken from the distribution
meta-data.

>> - Work left to do : publish the final syntax, and do the implementation

Is there a PEP for this ?

>> == The fate of bdist_* commands ==
>>
>> So the best way to handle this is to ask these communities to build
>> their own tool and to encourage them to use Distutils as a basis for
>> that.

Rather than having external communities build their own
tools and then basically fork distutils in order to get
these implemented, I think it'd be better to make the
set of distutils commands extensible via namespace packages.

>> So what is going to happen is a status-quo: no bdist_* command will be
>> removed but no new bdist_* command will be added. 

I hope that comment means "no new bdist_* command will be added
*right now*". It's well possible to create new bdist_* commands
that don't rely on external tool chains or only on ones that
don't change often.

I'm thinking of bdist_inno (Windows installer using InnoSetup)
and bdist_nsis (Windows installer using NSIS) here.

>> = Virtualenv and the multiple version support in Distribute =
>>
>> (I am not saying "We" here because this part was not discussed yet
>> with everyone)
>>
>> Virtualenv allows you to create an isolated environment to install
>> some distribution without polluting the
>> main site-packages, a bit like a user site-packages.
>>
>> My opinion is that this tool exists only because Python doesn't
>> support the installation of multiple versions for the same
>> distributions.
>
> Not only, for me it exists also to provide a way to isolate/chroot an
> application from the host system.

I agree: IMHO, that's the main use case for things like virtualenv.

Note that Python has had a PYTHONHOME environment variable for ages.
This pretty much serves the same purpose and together with setting
PYTHONPATH can easily be used to create your own private Python
universe.

>> But if PEP 376 and PEP 386 support are added in Python, we're not far
>> from being able to provide multiple version support with
>> the help of importlib.

Before putting much work into this: do you really think that having
multiple versions of the same package in the same Python installation
is a good idea ?

Examples:
What if you have an application that uses two modules which each
require two different versions of the same package ? Would that
load the same package twice, causing globals used by these package
to no work (e.g. isinstance(x, class_name) or global caches) ?

This sounds a lot like DLL- or RPM-hell to me.

I think it's much better to keep things simple and under user
control, e.g. by encouraging use of virtualenv-like setups
and perhaps adding better native support for these to Python.

If the user finds that there's a version conflict this can
then be resolved during environment setup instead of hoping
for the best and waiting for application failures at run-time.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 08 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/