In the Python world, there is no easy, standard way to package, distribute, build, test, and install add-on modules or extensions. This stands in sharp contrast to the situation with that other popular scripting language, where practically any module on CPAN (the Comprehensive Perl Archive Network) can be downloaded, unpacked, and processed in the following standard way:
perl Makefile.PL [optional KEYWORD=value arguments] make make test make install
This simple routine works for everything from a small, pure Perl module ("single .pm file" distribution) to the massive Perl/Tk distribution, with hundreds of C source files, dozens of Perl/C glue modules, and scores of Perl modules implementing higher level classes.
The key to the whole system is the MakeMaker module,
which makes writing Makefile.PL---the Perl script that
starts the whole thing going from the user's point of view---trivial
(usually). Makefile.PL simply instantiates the
MakeMaker class with some module-specific parameters,
and then asks the instance to write itself out (as
Makefile). The module-specific parameters range from the
simple and obvious (such as the module name and version number), which
have little impact on the generated Makefile, to
nitty-gritty build details such as C source files or libraries needed,
where to search for .pm files, particular .pm
files to use, and so forth. These latter parameters obviously affect
the contents of Makefile.
Python's lack---or rather, the Python community's lack---in this area
is partly technical and partly social. The technical challenge is to
come up with an analogue to Perl's MakeMaker module. While
the Makefile.pre.in semi-standard might appear up to the
task, I maintain that it is inadequate for a variety of reasons:
Makefile.pre.in that may diverge from a "standard"
one
Makefile when
one has the advantage of knowing there is already a modern, powerful,
high-level scripting language installed on the target platform? (After
all, the only reason people still write configure scripts
for most packages in shell is because we can't assume the presence of a
good language, like Python or Perl, on the target machine!)
The social engineering challenge will probably prove harder to
overcome. No matter how easy we make it to package and distribute a
tarball for Python module X, it will always be easier for the developer
to just put X.py on his web page and expect potential users
to download and install it themselves. The Perl community has addressed
this through an extensive and detailed set of guidelines (originally
published in the
Perl Module List,
and now also included in the
perlmodlib
manual page distributed with Perl) on the "right way" to create,
document, test, package, and distribute Perl modules.
There's still nothing to prevent me from just putting
X.pm on my web page and expecting users to download and
install it themselves. However, thanks to the extensive instructions in
the module list, the existence of an entire chapter of the Camel Book
devoted to "social engineering", and the wide acceptance and use of
CPAN, this simply does not happen. Module authors take the small amount
of extra time required to package their module in the accepted way, and
thus it becomes part of the accepted body of work. Modules not packaged
in this way are not generally considered "real" modules, and not
afforded the respect or recognition that they might otherwise
deserve.
Porting this social engineering effort to Python will require work on several fronts:
MakeMaker-like module for Python that makes
packaging and distributing Python modules almost as trivial
as putting the .py file on a web page