[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: Axiom package system

From: C Y
Subject: [Axiom-developer] Re: Axiom package system
Date: Mon, 19 Mar 2007 18:45:24 -0400
User-agent: Thunderbird (X11/20070308)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]