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.cava...@cavallinux.eu <mailto:a.cava...@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 | ncogh...@gmail.com <mailto:ncogh...@gmail.com> |
Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
