[Axiom-developer] Re: Axiom package system

[C Y]

Bill Page wrote:

> > One functionality for package authors that would be really
> > nice is a way to automatically generate a list of
> > functionality they are using in all the code in a file or
> > package.  This is particularly good for cases where multiple
> > packages outside the main Axiom tree are used together
> > and thus one or more requirements might not be present
> > "by default."
>
> I do not know what you mean by "list of functionality". Could
> you explain? Can you give an example of this in any existing
> package management system, e.g. Debian apt-get, RedHat Yum,
> etc. ?

Sorry, I probably didn't say it right.

Let's take an example - say that, hypothetically, a units package and an 
error analysis package have been implemented as packages external to Axiom.

Now, say I want to implement a version of Feyncalc in Axiom that builds 
off of those core packages.  As I develop the new Feyncalc, I would have 
the other packages I depend on loaded.  However, when I went to pack it 
for distribution, I would want to know what I had loaded and wound up 
using that isn't part of the default Axiom.  A command that could 
determine what parts of the system and any loaded packages were used, 
and flag any 3rd party packages, would be a useful utility.  In 
addition, I might find I have used only a very small part of some 
package and it might be useful to incorporate that small part into my 
own code to avoid the external requirement. Later I could use the same 
mechanism to check if it has become part of the main Axiom, which would 
help pinpoint possible conflicts and help keep my code clean.

I was thinking working at the domain level or whatever level makes 
sense, sort of a "deep requirements" map of a package at a mathematical 
level.  Maybe something similar to xref in lisp.

Another possible use would be to quickly check if my 3rd party package 
depends on any parts of Axiom that have been updated in a given release. 
 If so, checking is indicated, and if not it's probably a fairly safe 
bet that everything is OK.  Eventually a unit testing system might take 
advantage of this to trigger checks automatically on commits - check all 
functionality which relies on the code which has just been changed. 
Perhaps there are better ways of doing that, it's just an idea. 
Obviously it's a bit more of a development tool than a package tool, but 
it would help in building external packages.

Cheers,
CY