[Distutils] My view of installation control

[John Skaller]

Here is roughly what I am planning for interscript
installation control.

Executive summary
-----------------

1) In the source, the author provides category tags
for files. 

2) The client is required to bind the tags to 
installation points.

Explanation
-----------

Clients may wish to install parts of packages
in different ways. For example they may
wish to install doco in the same directory
as each module:

        package/something.py
        package/something.html

or in separate isomorphic directories:

        code/package/something.py
        doco/package/something.html

There are a lot of variations on this scheme,
and we must cope with ALL of them.

To do this, we rely on the AUTHOR to identify
the category of a file by tagging it: the file
extension can be used for defaulting, as well
as a few other things (such as the kind of
generating process).

This means that absolute filenames are 
not allowed in the source package.

The CLIENT must be able find out what tags
the author used, and provide a binding
to an installation point for every file
based exclusively on the tags of that file.

For example: for a PY file, the installation
point might be deemed 

        /usr/local/lib/python1.5/site-packages

and the [DOCO, HTML] installation point might be

        /home/httpd/html/python/installed-packages

This mechanism is NOT enough, but it should
cover a very wide variety of cases.
[See below]

        The issues involved are:

1) how does the author decide what tags to use?

2) how does the client find out what the tags
the author used are, and what they are intended
to mean?

3) how does the client specify the binding
of tags to installation points?

---------------------------
[Below]

There is a more general solution than mere tags,
which I'm working on. The basic idea is that
the author provides a _category_ which defines
the abstract structure of the package,
and the client provides a _functor_ which binds
the category to the installation space.

This mechanism is fully general, it can necessarily
do everything. Of course, the source category
has to be specified, which limits the domain
to those categories for which there are effective
implementations; the same comment applies
to the installation functor.

This mechanism has many advantages, apart from
complete generality. The main one is that
the installation function can be _verified_
with many representations, that is, it can 
be checked mnechanically that the installation
mapping preserves the abstract structure
of the package.

With some modifications to the aboave abstraction,
installation can be extended to upgrading.

This mechanism automatically subsumes all notions
of version control, dependency checking, etc.
It allows, for example, any kind of version
numbering system _provided that system
is coherent_, (where coherent has a very
precise meaning).

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia