in a class attribute 'sub_commands', rather than hard-coded in 'run()'.
This should make it easier to subclass 'install', and also makes it
easier to keep 'run()' and the new 'get_outputs()' consistent.
Added 'get_outputs()' in preparation for the 'bdist' command.
these must come from the 'build' command. This means we no longer need
the misconceived 'set_peer_option()' method in Command and, more importantly,
sweeps away a bunch of potential future complexity to handle this tricky
case.
this command for a while; this implements roughly the plan cooked up by
Guido, Fred, and me. Seems to strike a nice balance between usability in
the common cases (just set one option), expandability for more types of
files to install in future, and customizability of installation
directories.
This revision isn't completely working: standard and alternate
installations work fine, but there are still some kinks to work out of
customized installations.
'--help-commands' option).
Shuffled imports around in a few command modules to avoid expensive
up-front import of sysconfig (and resulting delays in generating list
of all commands).
Tweaked some help strings to be consistent with documentation.
Don't call 'set_final_options()' in 'run()' anymore -- that's now
guaranteed to be taken care of for us by the Distribution instance.
distributions their own directory (and .pth file).
Overhauled how we determine installation directories in
'set_final_options()' to separate platform-dependence and take
'install_path' option into account.
Added 'create_path_file()' to create path config file when 'install_path'
given.
Only run 'install_py' and 'install_ext' when, respectively, there are
some pure Python modules and some extension modules in the distribution.
'install_site_lib' and install_site_platlib' on non-POSIX platforms.
Should at least work for NT, as this is adopted from Amos Latteier's NT
patches. Also added extensive comments bitching about the inadequacy of
the current model, both under POSIX and NT (and probably other) systems.
of the 'install_py' command rather than 'build_py'. Obviously, this
meant that the 'build_py' and 'install_py' modules had to change; less
obviously, so did 'install' and 'build', since these higher-level
commands must make options available to control the lower-level
commands, and some compilation-related options had to migrate with the
code.
Greg Ward