[Distutils] Installing large applications

[Mark W. Alexander]

On Wed, Jun 16, 2004 at 09:45:17AM -0400, Jim Fulton wrote:
> Zope actually takes this a step further by having "instance"
> installations.  To set up a zope installation, you first install the
> software (hopefulling using a distutils-based installer) and then use
> an installed program to create one or more Zope "instances". Each
> instance runs a Zope application server and has instance-specific
> configuation, data, *and* library areas.  Someone could install custom
> versions of software into an instance area, overriding other versions
> in the Zope or Python library areas.
> 
> So, in summary, an application might add multiple librariy areas. The
> application *is* responsible for adding these to sys,path on startup.

I've never run Zope on Windows, but I've loved seperate instance dirs since
they where a hack. It seems to me that to meet a Windows user's
expectations, mkinstance.py should invoke a setup.exe-style wizard and
update the registry with appropriate uninstall information and add
start/stop entries to the menu. (I doubt that *nix users have the same
expectation, and it would require an appropriate bdist_* invocation
anyway, so I wouldn't bother there.)

It seems outside the scope of Distutils, although transforming
mkzopeinstance.py to a setup.py model and wrapping a Windows
Wizard face around it may be an implementation option. Since
mkzopeinstance doesn't need to compile any C stuff (already done for the
core installation), it should "just work" like any other Windows
installation.

This still leaves outstanding a fundamental point I've stressed before
about bdist_* commands. The resulting packages really need to be
relocatable on platforms that support package relocation. Those geeky
admin types doing the installation may need a test tree and a production
tree, or they may need an application specific tree (for example, I run
a separate Python installation on Debian for Zope, so `apt-get python`
doesn't inadvertantly switch me to a python tree missing modules needed
for Zope, Zope products or deployed external methods). 
	
In one way or another, most platforms' native package managers support
relocation, although many require using different package _names_ to do
so. This a burden on the installation end that distutils core does not
readily address. It also completely foobars attempts to do automated
dependency analysis based on package names. More flexibility in bdist_*
produced packages is required, by supporting more robust default
pre/post install/remove scripts and more intelligent interpretation of
"provides" and "requires" metadata (vs. package names) to include
identification of the installation location and what the stuff _there_
provides. Package managers can usually do this, if they are just given
the right information.

Ok, I'm ranting a bit, but why stop now... What I'm trying to express is
that I really feel that both the Distutils and the Catalog sigs are
missing the mark by apparently shooting for what CPAN does: assuming an
enterprise admin will use `python setup.py install` as an installer on
hundreds of production servers (most of which shouldn't have a compiler
installed) and assuming that a python package repository that's not
integrated into the native platform package management will be helpfull.
It's really not, at least not for more than a handful of machines. It's
definitely not in a multi-host, service oriented architecture, where
applications are services and can "float" from machine to machine where
you have to be absolutely sure of your package inventory on every
potential host.

So let me toss this out as a "vision." Distutils needs more emphasis on
flexible, relocation-aware bdist_command implementations so that
packages get picked up by packagers, ala Debian packagers, RH packagers,
SunFreeware.com packagers, HP Software and Porting Archive packagers,
etc. There's a whole population of people out there that do just that:
make packages. Admins and users can then get python packages where they
get all other packages for their platform. The catalog should be a
reference for packagers and could possibly be backended by a
cross-compiling utility to produce platform native packages on demand so
platform packagers can easily extract them into distro/platform
repositories and be confident that they will conform to the standards of
their platform.

It seems to me that something like this would promote python package
availability and portability far more effectively than an independent
CPAN-like suite. CPAN is "perl modules, by perl people, for perl people".
Positioning Distutils and the Catalog as "Python and extra batteries for
the platforms" is a better marketing position. It provides an easier
administrator interface, which in turn promotes broader Python and
Python package adoption, which feeds the desire for more packages.

mwa
(Not cross-posted to catalog-sig, since it's bad form to forward Jim's
comments to another list, but if anyone cares enough to route this rant
that way, and feels it's constructive, feel free to snip & forward.)
-- 
Mark W. Alexander
slash at dotnetslash.net

The contents of this message authored by Mark W. Alexander are
released under the Creative Commons Attribution-NonCommercial license.
Copyright of quoted materials are retained by the original author(s).

http://creativecommons.org/licenses/by-nc/2.0/