Status of my packaging system

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Status of my packaging system

Søren Hauberg
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.

/Søren

Reply | Threaded
Open this post in threaded view
|

Re: Status of my packaging system

David Bateman-3
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                                [hidden email]
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