Re: Package system

[Søren Hauberg]

Hi,
Thanks for the info on octave-forge.

lor, 22 10 2005 kl. 16:59 -0400, skrev Paul Kienzle:
> - main/audio creates a binary that should be installed in the helper 
> binary directory.  I put them into octave_config_info 
> ("localverarchlibdir").
One problem with this is that not all users have write access to this directory.
Would it be possible to install this binary somewhere else, or would we
loose functionality then?

> - main/audio/data has a sample wav file which I install into the data 
> path for the package.  In this case, I simply use the package path 
> itself and find from the script using file_in_loadpath('file.wav').
I see you simply put the .wav file in the same directory as the .m files, so 
the easy 
solution is simply put the .wav file in the 'inst' directory. However it might 
be a good 
idea to provide some standard way to provide sample data with a package.

> - main/comm/doc has texinfo documentation which should be built and 
> installed in the usual texinfo places.  Pure documentation packages 
> such as doc/coda are also possible.
Yesterday, I submitted a patch to the bugs list (not a very good patch, but 
still) that makes
'help -i function' look for a file called doc.info in the directory
where 'function' lives, and if this file exist use it. If such
functionality gets integrated we would have a standard way of providing
documentation with packages.

> - main/control is an example of a single function package intended to 
> extend an existing package.  Does it need its own directory?  Or can we 
> request that it be installed in the same directory as the control 
> package, while updating the list of functions reported by "help 
> control"?
Hmmm, currently the answer is no. I need packages to go into separate 
directories in order
to make uninstallation easy. I'd really like not to keep track of each
file provided by a package, as I think this makes the system more
simple. It is however possible that it becomes to simple...

> - extra/engine has libraries and headers that are needed by other 
> programs.  They should be installed in /usr/include and /usr/lib or 
> /usr/local/include and /usr/local/lib.
>
> - extra/mex and main/fixed have libraries and headers that need to be 
> available for compiling other oct-files.  They should be installed 
> along side the octave libraries and headers.
The problem here is that not all users have the privileges to do this. We could 
of course
check this and tell the user if she doesn't have the needed privileges.
This should be possible in the current setup, by providing
'pre_install.m', 'post_install.m', and 'on_uninstall.m'. These could
also handle the installation of the files. However, this really isn't a
very pretty solution (it's really a hack). Personaly, I don't think the
package system should take extra care to make packages like this
possible as I'm guessing there won't be many packages like this.

> - extra/graceplot introduces alternatives. The package system should 
> support this in some way so that the user can toggle at run time 
> between graceplot and gnuplot.  extra/nan, which replaces some standard 
> octave commands with alternatives which ignore NaN, could also be 
> handled with alternatives.
Hmmm, I guess that 'pkg load' (or whatever name we choose) could add the
package to the beginning of the path, thereby overriding other
functions. The user can then choose which functionality to use by the
order in which packages gets loaded. Not very user-friendly, but it
should work.
As to the gnuplot/graceplot issue, would it be possible to provide
gnuplot as a package as well (removing gnuplot from core octave)? That
way the user could choose which system to use by loading the right
package. (This reminds me that we should have a 'pkg unload' (or
whatever naming we use))

> - extra/perl and extra/soctcl are packages for other languages so they 
> are not our problem ;-)
I do love the use of a "Not My Problem Field" :-)

> - extra/MacOSX and extra/Windows are system dependent.  It's the user's 
> problem to decide whether or not to install them.
Makes sense.

> - configure.base contains configure information useful to a number of 
> packages.  Much of this is available in modern versions of octave, 
> through system commands such as octave-config and through the octave 
> command octave_config_info.  Other things such as the flags to the cp 
> command, and the details of txi->info conversion should be part of the 
> packaging system.
Couldn't this file be maintained by octave-forge and then copied to the 
packages that need 
it? As to the txi->info issue, I think we need a standard way of providing 
extra 
documentation (see above).

> - anticipate translated help files for multiple languages as part of 
> the package.
I don't really know how this is going to be implemented. What is the
needs of the translation project?

> - I didn't see where you created the PKG_ADD file by extracting PKG_ADD 
> lines from the individual m-files.
I don't, because I really don't know what that means :-)
What is PKG_ADD?

> Some more general comments:
> 
> - package version should be available at run time.  Currently I have 
> OCTAVE_FORGE_VERSION.m for all the packages.  Maybe a version 
> subcommand on the pkg command is the best way to handle this?
Guess you're right. It was mentioned that matlab has a 'ver' command, which 
could be 
implemented on top of 'pkg list'. Perhaps this would give the needed infomation.

> - we should be able to build and test the packages before installing 
> them.
Yes! Octave-forge has scripts to handle this, right? Could these be integrated 
with octave?

> - we should note whenever a installed command shadows an existing 
> command.
Good idea. Shouldn't be to hard to implement.

> - in octave forge most tests are embedded in the files themselves and 
> discovered with admin/mktests.sh.  The tests should be installed along 
> with the functions so that the user can see at run time what tests the 
> function is supposed to pass.  Also some tests are actually demo blocks 
> which are part of the documentation of the function.  Some tests are 
> embedded in C++ files.  These will need to be extracted before 
> installing.  In retrospect tests should perhaps be in separate .test 
> files in both cases, and maybe separate .demo files for the demos.
So what you're suggesting is that octave provides two function
*) test('somefile.test')
*) demo('somefile.demo')
And that packages provide the .test and .demo files?

> - for windows systems which may not have the compilers installed, we 
> may want to support binary packages.  This would be advised for OS X 
> systems as well, where tracking down and installing third party 
> libraries prior to installing the package would be a pain.
I choose not to call 'make install', but instead move files from the 'src' 
directory
to the 'inst' directory, to make creation of binary packages easy. While
not implemented, it should be very easy to create binary packages.
Simply stop the installation before installing any files.
So it's not implemented, but it's on the todo :-)

> - the packaging system should be available and useful for matlab as 
> well.  That way authors of packages such as wavelab will have less work 
> to do to support octave.  For example, if you automatically generate 
> the contents.m from INDEX and admin/make_index the contents file will 
> be easier to maintain and it is a win for them.  Similarly, we should 
> Do the Right Thing with a usual matlab tarball which has contents.m 
> rather than COPYING DESCRIPTION and INDEX files.
In general, I think we should provide scripts for creating different kinds of 
packages.
It seems like we need .rpm, .dep, and perhaps also matlab package
creator scripts. I don't know the first thing about any of these
formats, but we should have this functionality. Perhaps a 'Package
Creator' package should be available?

Once again, thanks for the input
Soren
> Paul