[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