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