Module and feature dependencies

[Paul Boddie]

Well, after stating that I had no interest in writing a PEP, some
thoughts of mine evidently floated up into my consciousness, leading
to this vague enhancement proposal.

Despite the publication of certain proposals about introducing version
identifiers into the Python syntax, indicating the version of Python
for which a particular program is intended, such syntactic
enhancements have been regarded as unpleasant or unnecessary. Indeed,
in the context of the PEP 238 debate, the introduction of such
identifiers to indicate that a program is to adopt the newer division
semantics seems to be viewed as a "hack". However, such a debate is
unlikely to entertain consideration of wider issues with the
dependence of programs on particular features of Python and on other
Python modules, packages and extensions.

Consider Pygame (http://www.pygame.org). This package has a selection
of dependencies which the author has conveniently published (and I
hope he doesn't mind me using his work as an example). Unless explicit
verification of those dependencies have been coded into the Pygame
framework, and I'm not sure that they have been, then surprises can
result for those who have not paid appropriate attention to the
published documentation. These surprises can occur quite often when
compiled extensions are obtained for different versions of Python or
external libraries.

Whilst installing a package without paying full attention to the
published documentation could be considered foolish, it should be
remembered that human-readable documentation residing in a particular
location (in this case the package's Web site) does not necessary help
users obtaining the package from other places (such as mirror sites or
other media), nor does it help automated installation systems.

What seems to be necessary is a general dependency tracking mechanism
which will not only guard against the execution of Python programs in
environments lacking the prerequisite features, modules, extensions
and libraries, but also to allow the detection of dependency problems
in advance (before execution or even installation is attempted). One
way of achieving this may be to introduce declarations within program
files which are analysed when a program is run, but which can also be
analysed by other programs.

Of course, many systems exist which address most of the obvious issues
in this area. Package systems at the operating system level (eg. RPM,
pkgadd) can track library dependencies, configuration and build tools
(eg. autoconf, configure, make) can determine whether source code is
appropriate for a given environment, and Python has its own emerging
build infrastructure (Distutils). Nevertheless, this problem area is
worth reinvestigating with attention to PEP 241 ("Metadata for Python
Software Packages"), PEP 243 ("Module Repository Upload Mechanism"),
as well as Distutils.

This message really does state the obvious, and personally I think I
manage quite well with the dependencies my works have on other things.
However, outside my own mechanisms for managing such issues, such as
on the rare occasion when my works are downloaded by others, the
recipients of those works may not be as well protected as I am from
the dangers of version mismatches. Being able to encode dependencies
in a portable form could do a lot to make module and extension
installations easier.

Paul