[Python-3000] Proposal: No more standard library additions

Talin talin at acm.org
Mon Oct 23 02:50:47 CEST 2006


Greg Ewing wrote:
> Martin v. Löwis wrote:
> 
> I agree that Make itself doesn't handle install-type
> operations very well. I think that's partly because
> it's too rigidly fixated on a target being a single
> file.

This isn't related to Py3K, except that it would solve a lot of problems 
in Python if it were true: When is the world going to invent a decent 
make replacement?

I bring this up because I recently (like - today) spent about 8 hours 
trying to debug a Python installation problem - and realizing that much 
of the reason that installation and deployment infrastructure of Python 
programs is so ****ing complex is because of the poverty of tools like Make.

Right now, the top competitors for Make are (as far as I know):

   -- pljam: Nice system, but effectively unmaintained
   -- SCons: again, nice system, but doesn't scale, performance is
             unacceptable for large projects.
   -- ant / nant: Heavy requirement on Java / .Net

There are others out there, nmake, image, etc. None of them have 
succeeding in supplanting 'make' in any serious way.

Most of the potential make alternatives have a fatal flaw in that they 
are not bootstrappable - they require a large body of software to be 
installed before they can even run (like Python, Java, .Net. etc.) Any 
new make-replacement would have to deal with the fact that 'make' is 
already pre-installed on everything except Windows, whereas this system 
would need a way to bootstrap itself onto systems where it was not 
already installed (perhaps using a single C source file as the initial 
bootstrap starting point.) Otherwise, no one will seriously consider 
using it as a basis for deployment of products.

Another fatal flaw of (some) of these systems is that the build script 
files are designed to be 'interpreted' as opposed to 'inspected' - in 
other words, they are useless as metadata. A modern system would need to 
do both - to not only be executable, but to be manipulable/transformable 
in a larger context.

I've often thought about taking a few months and building something that 
would solve all of these problems, but then I stop and I realize that 
I've only personally encountered a small fraction of the problems that 
need to be solved - so all I would accomplish is solving all of my own 
problems, and not everyone else's.

(Sorry for going off-topic, but its a hot issue for me.)

-- Talin


More information about the Python-3000 mailing list