On Mon, Dec 10, 2012 at 1:22 AM, Antonio Cavallo wrote:

I'm not into the py3 at all so I wonder how possibly it could fit/collide into the big plan.

Or I'll be wasting my time?

If you're not doing it on Python 3 then you are wasting your time.

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). Lennart Regebro wrote:

On Mon, Dec 10, 2012 at 8:22 AM, Antonio Cavallo wrote:

...

Hi, I wonder if is it worth/if there is any interest in trying to "clean" up distutils: nothing in terms to add new features, just a *major* cleanup retaining the exact same interface.

I'm not planning anything like *adding features* or rewriting rpm/rpmbuild here, simply cleaning up that un-holy code mess. Yes it served well, don't get me wrong, and I think it did work much better than anything it was meant to replace it.

I'm not into the py3 at all so I wonder how possibly it could fit/collide into the big plan.

Or I'll be wasting my time?

The effort of making something that replaces distutils is, as far as I can understand, currently on the level of taking the best bits out of distutils2 and putting it into Python 3.4 under the name "packaging". I'm sure that effort can need more help.

//Lennart

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

It is not that complex... What's ahead is even more complex. Lennart Regebro wrote:

On Fri, Dec 14, 2012 at 9:49 AM, Antonio Cavallo wrote:

...

My requirements would quite simple: 2. cross compiling

That is *not* a simple requirement.

//Lennart