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. Thanks Nick Coghlan wrote:
On Fri, Dec 14, 2012 at 10:10 AM, Antonio Cavallo
mailto:a.cavallo@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.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com mailto:ncoghlan@gmail.com | Brisbane, Australia