[Distutils] Installing large applications

[Tim Peters]

[Fred L. Drake, Jr.]
>>> A new command-line option will be added to allow the location to be
>>> changed.  "install --application <name>" will cause the installation to
>>> occur in /opt/<name>/ (or some Windows equivalent)

[Tim Peters]
>> There seems to be an assumption that <name> includes a version number.
>> Then plain \<name> or <drive>:\<name> may be suitable on Windows.

[Jim Fulton]
> I don't understand this.  How does the presence or absense of a version
> number affect wither you use a root directory or a drive letter?

Too much context was snipped (long before your reply -- not your doing).  In
context, Fred suggested:

    One interesting aspect for such applications is that it is often
    desirable to install multiple versions of the application on a
    single system.  This is often needed when evaluating new versions
    to determine whether an upgrade may be performed safely, or whether
    new features are sufficiently valuable to incur the cost and risk
    of data migration. A version number.

If "--application <name>" is to be useful for *that*, then in still seems to
require an assumption that <name> includes a version number.  There's
nothing other than <name> *to* distinguish "multiple versions of the
application on a single system".

If it does include a version number, then \<name> or <drive>:\<name> may be
suitable on Windows.  That part is in contrast to the quoted suggestion that
on Unix installation occur in /opt/<name>.  "/opt" wouldn't make any sense
on Windows.

> The point is that the windows installer for an application should allow
> the user to select a directory to install into.

That's fine so far as it goes.

> (IMO, the default, for an application, should be in "Program Files".)

That makes good sense if and only if the user isn't expected to run commands
from "a DOS box" that refer to a file in the application.  It also requires
extreme care to write Python code "that works" with system calls involving
paths with embedded spaces (I have things like os.system(), .spawnv(),
.popen() in mind -- someone who normally codes on Linux has virtually no
chance of getting this right -- cmd.exe isn't bash, and command.com isn't
even csh <wink>).

>> I'm not sure how much this proposal is intended to address.  An
>> application like Zope expects some of its components (like ZODB) to show
>> up on sys.path, without any runtime code of its own fiddling sys.path to
>> make that happen.

> No.  Generally an applucatin will have it's own library area(s), which
> will be added to sys.path on startup.  So, the version of ZODB that comes
> with an application would typically be installed in the application's
> library area and would override any version installed in the standard
> library or site packages.

This is (almost) true of Zope 2 on Windows today but not of the Zope X3 beta
release.  Because the latter was built with distutils, it installs ZODB (and
friends) as top-level packages in (typically) \Python23\Lib\site-packages\,
so ZODB (and friends) are importable without any action on Zope X3's part.

So what you describe isn't true of current reality -- but I don't know
whether it was intended to be.

> In addition, users will often want to install custom versions of
> libraries for an application.
>
> 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.

That almost works in Zope 2 on Windows now, but not quite.  I've mentioned
before that the Zope Windows issues haven't been completely ironed out even
for Zope 2 with a custom, hand-built installer.  On Windows other packages
can try to muck with sys.path too, and Zope 2 doesn't manage to outguess all
of them (in particular, Zope2's attempt to supply its own win32all is
clobbered if the user installs their own win32all too -- and doing so has
the odd side effect of putting the native Python's Lib/site-packages ahead
of all Zope's sys.path tricks).

The devil is in the details, and because sys.path is a shared, global Python
resource, "surprises" when multiple apps try to muck with it at the same
time are inevitable.  If we assume Zope is the only Python app on the
machine, of course it's much easier to reason about.

> So, in summary, an application might add multiple librariy areas. The
> application *is* responsible for adding these to sys,path on startup.

I certainly agree it *should* be responsible.  The distutils-produced
Windows installers today are really best suited to general-purpose Python
libraries (like numarray and mxDateTime -- additional facilities for Python
programmers, not applications).