[Python-Dev] [Distutils] Is is worth disentangling distutils?

[Antonio Cavallo]

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
> <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.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   | ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |
> Brisbane, Australia