Re: Status of my packaging system

[David Bateman]

Søren Hauberg wrote:

> Hi,
> As some of you might know I've been working on a simple packaging 
> system for Octave (you can get it at http://hauberg.org/octave-package).
>
> The current status is that I've just done some minor clean up in the 
> code to give better error messages. I'm sure there's still bugs left, 
> but I'm not going to spend time on testing until I'm sure the ideas 
> are what Octave needs.
>
> Currently the code will
> *) Perform dependency checking at install and uninstall time.
> *) Generate an INDEX file for the package if none is given as part of 
> the package. (This allows us to have the help("packagename") 
> functionality).
>
> I guess my question is what am I missing in the current implementation?
> Things I would like to see, but don't know how to do is,
>
> *) A package should be allowed to install ekstra documentation for 
> info. The packager should not be forced to put all documentation in 
> the text that gets presented with help function_name, but also have 
> the option of  writing the help -i function_name documentation.
> *) Optional fetching of dependency packages. I think this would 
> require some server side scripting, so this is properly to much work 
> to be worth the hassle.

I felt the same, but couldn't get around the issue in the past as "help 
-i" just searchs the existing octave manual. I think it will be very 
difficult to add sections to this manual as you add the package. My way 
arounf the issue in the past, was to have a function named after the 
toolbox, that if

1) Called without arguments gave basic help and description of the toolbox
2) Called with ('test') ran all tests, or ('test','module') ran the 
tests for only 'module' of the toolbox
3) Called with ('info') ran "info --file toolbox.info", and if called 
with ('info','node') ran "info --file toolbox.info --node node"

Something like this might be a way around the issue, and in fact this 
function might be created automatically from the DESCRIPTION.. Check the 
comms.m and fixedpoint.m functions for what I
did. I didn't use Paul's test/assert code, but if this was done 
automatically it would have to rely on test/assert.

Cheers
David


--
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary