[Distutils] "setup.py needs to go away" (was [PEP 376] - Open questions on python-dev)

[David Cournapeau]

Jim Fulton wrote:
>
> On Jul 12, 2009, at 6:24 AM, David Cournapeau wrote:
> ...
>> That relates to the "python needs to be a platform" idea.Taking again
>> the numpy/scipy case, I would love to get something like a robust
>> easy_install, where scientific toolboxes can be installed, queries,
>> uninstalled from pypi.
>
> I don't understand what you mean by "queries, uinstalled from pypi".

Sorry, the bad grammar did not help to make the point very clearly. My
ideal scenario would be, inside a python session:

>>> pkgs = look_for_packages(keywords=['image', 'signal', '3d']) #
return a list of packages related to those keywords
>>> for p in pkgs: print p.description # Get the description
>>> install_package('some_package')
>>> ....
>>> upgrade_world() # Upgrade every package and their dependencies
>>> uninstall('some_useless_package')

This would work as a normal user (no admin privileges required), and it
has to be robust. It should (up to some point, there will always be some
friction here) play happily with the system packager if there is any.

>
>> Having our own 'python' for installation, would
>> make this much easier - but we loose what makes numpy/scipy so
>> attractive in the first place, that is using a lot of great packages
>> outside the numpy/scipy community.
>
> Why would you lose anything? You can include any additional tools you
> want.

The user would loose the ability to install packages whose binaries are
built against the python distributed by python.org. Especially on
windows (compilation issues), and on a less degree, mac os x, that's a
killer.

>
>> Those two goals kind of contradict
>> with each other, I am not sure where the trade-off should be.
>
> I'm not sure exactly what you mean, but I think this gets back to my
> original point.  Sometimes you want to provide people a robust 
> application that addresses a fixed set of use cases. Sometime you want
> to provide a toolbox that allows people to address ad hoc problems.  

And sometimes, we want both :)

> I doubt it has anything to do with Python.

I can already cite two python shortcomings which cause issues for the
above scenarios: ABI issues and no "versioned import" support.

> Well, I'm more familiar with buildout. :) Buildout makes it
> straightforward to control precisely the packages in your
> application.  A tool named zc.sourcerelease, let's you build a release
> that contains a particular configuration of packages with an install
> script that installs them.  (This isn't limited to Python packages
> either.  It can include 3rd-party applications such as libraries,
> database servers, etc. -- anything that's installed with a
> configure-make-make-install dance.)

This sounds a bit like the gar system:

http://www.lnx-bbc.com/garticle.html

Except gar is based on makefiles.

> This source release then becomes the basis for an installer.  We use
> it to create RPMs for our applications.  Because we use RPM, our
> applications can share a common "clean" Python RPM that has what you'd
> get from a source install of Python.  We don't include Python in the
> application RPMs, although it would be pretty easy to do so.

Ok. That sounds indeed like one step in the good direction. Although
deployment issues will always be difficult, repeatability helps a lot
toward making it less painful. I see repeatability as the common ground,
and precise requirements as a 'special case' of repeatability.

David