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

M.-A. Lemburg mal at egenix.com
Thu Oct 8 13:27:57 CEST 2009

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 easyinstall, 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/

More information about the Python-Dev mailing list