[Distutils] Distutils and Applications

[M.-A. Lemburg]

Fred L. Drake, Jr. wrote:
> The distutils package has generally proven to be a quite useful tool
> to support building and installing Python modules and packages.
> There's some limited support for installing scripts and data files,
> which makes it somewhat useful for larger applications.  Large
> applications can have complex requirements for installation, however,
> and distutils has some limitations that could be addressed.

I think that distutils should not try to become another
installer (like Inno Setup, InstallShield, etc.).

> Larger applications generally want a number of features that aren't
> currently supported by distutils:
> 
> - They want to be isolated from the rest of the platform, and not
>   generally have their code installed into the site-packages/
>   directory.  Normally they don't want to share the platform's Python
>   installation, if there is one.

True. Don't see what distutils has to do with this, though.

> - They may want to install 3rd-party packages into their isolated
>   environment as well, in addition to their own implementation.  It
>   should be easy to take a package containing a 3rd-party package and
>   bundle it with the application or to install it later.

This really depends on the third party package. I don't
see how distutils can help with this.

> - It must be possible for scripts to behave in the ways that are
>   expected on the host platform.  This includes the presence/absence
>   of filename extensions.

I remember that we discussed this some time ago. Wasn't there
a new option to deal with this at install time ?

> - Particularly elaborate "platform" applications (such as Zope 3) may
>   want to support multiple "extension" areas which can then be "bound"
>   to different versions of the application software.

That's definitely outside the scope of distutils. How
you setup your PYTHONPATH is really up to the application.

> - It should be possible to perform installation in a "silent" mode
>   that does not requre interation with a human.  This is especially
>   important to support managed deployments.  It should be possible to
>   specify the installation location using a command line argument.

On Unix, there's no problem with this, so I guess you're
talking about Windows here. However, this is a problem with
the installer you've chosen and not with distutils.

> - Conventional packaging structures for each platform should be used.
>   For Unix, this means it should be able to create a tarball that
>   supports configure/make/make install, and for Windows, either a
>   conventional executable installer or an MSI installer (or both).
>   (Remember, the consumers are not necessarily Python programmers.)
> 
> Some of these may be best provided by extensions to distutils, and
> others may be best provided by separate utilities.  I'd like to figure
> out what portion of this is shared and should be supported by
> distutils, and what should remain outside distutils.

IMHO, distutils should not evolve to a complete cross-platform
installer replacement.

It could be made easier to build these
installers, e.g. by having distutils prepare everything nicely
for the installer builder application to work with, e.g. have
it build the application and generate manifest files for the
installer configuration scripts to include.

It would also help if we could use Python and distutils
within the installation step or as last step. Having a
standard way of communicating the information about the
installation (e.g. install path, user entered parameters,
selected options, etc.) to the partially installed application
would be great, since then most of the dynamic install
mechanisms could be written in Python as well and replace
e.g. Pascal code that you currently have to write for
Inno Setup.

> Anything of this that could be shared (in or out of distutils itself)
> we can work on at PyCon in the distutils sprint:
> 
>     http://www.python.org/moin/DistutilsSprint


-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 03 2005)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::