[Python-Dev] [Distutils] Is is worth disentangling distutils?
a.cavallo at cavallinux.eu
Fri Dec 14 09:49:44 CET 2012
Mmm, so the question would be distutils2 or distlib? I think tarek made
a graph of the different packages systems... seen on reddit some time ago.
My requirements would quite simple:
1. support DESTDIR approach where a package can be installed in an
intermediate directory before its final destination)
2. cross compiling
3. install even if a dependecy package is not installed so decoupling
installation from "configuration"
point 1 is needed for system integrators (eg. people working in rpm builds).
point 2 is entirely mine :)
point 3 is the same philosophical difference between build, install and
configuration steps: its part of good practices. In short it shouldn't
replace the system wide dependency manager (in rpm it would be yum/zypp
and in debian is much more confused, in window.. it doesn't exists as
well in macos having the approach to pack it up everything in one place).
Funny enough distutils (the old dead horse) does it all except point 2:
that is my reason to clean up the code. I've just seen py3k distutils
but it would be worth a back port to py2k.
Nick Coghlan wrote:
> On Fri, Dec 14, 2012 at 10:10 AM, Antonio Cavallo
> <a.cavallo at cavallinux.eu <mailto:a.cavallo at cavallinux.eu>> wrote:
> I'll have a look into distutils2, I tough it was (another) dead end.
> I every case my target is py2k (2.7.x) and I've no case for
> transitioning to py3k (too much risk).
> distutils2 started as a copy of distutils, so it's hard to tell the
> difference between the parts which have been fixed and the parts which
> are still just distutils legacy components (this is why the merge back
> was dropped from 3.3 - too many pieces simply weren't ready and simply
> would have perpetuated problems inherited from distutils).
> distlib (https://distlib.readthedocs.org/en/latest/overview.html) is a
> successor project that takes a different view of building up the low
> level pieces without inheriting the bad parts of the distutils legacy (a
> problem suffered by both setuptools/distribute and distutils2). distlib
> also runs natively on both 2.x and 3.x, as the idea is that these
> interoperability standards should be well supported in *current* Python
> versions, not just those where the stdlib has caught up (i.e. now 3.4 at
> the earliest)
> The aim is to get to a situation more like that with wsgiref, where the
> stdlib defines the foundation and key APIs and data formats needed for
> interoperability, while allowing a flourishing ecosystem of
> user-oriented tools (like pip, bento, zc.buildout, etc) that still solve
> the key problems addressed by setuptools/distribute without the opaque
> and hard to extend distutils core that can make the existing tools
> impossible to debug when they go wrong.
> Nick Coghlan | ncoghlan at gmail.com <mailto:ncoghlan at gmail.com> |
> Brisbane, Australia
More information about the Python-Dev