Re: packaging aesthetics

[Paul Kienzle]

On Feb 14, 2007, at 6:53 AM, David Bateman wrote:

> Paul Kienzle wrote:
> > I find I'm bothered by the packaging directory structure since it
> > doesn't feel natural to me.
> >
> > I would prefer a system which captures the 90%+ case easily, which is
> > a set of m-files with a few decorations to tell the packaging system
> > what the package contains.  In Debian, the package information is in
> > subdirectory, which allows it to be easily added to an existing
> > package.  This makes it particularly easy for those with existing
> > Matlab packages to add support for Octave, assuming various other
> > compatibilities are not a concern. It also allows the packaging to be
> > done by someone other than the developer.  Keeping the compiled
> > wrappers, supporting libraries, documentation and so on are separated
> > from the rest would probably be best, but the impact of these is small
> > so it doesn't matter much either way.
> >
> > Of course since I'm not offering up any patches this message should be
> > given the weight it deserves 8-)
> >
> >     - Paul
> Paul,
>
> If I understand what you are proposing, is to have all files in the 
> root directory of a package be installed and the sub-directories get 
> special treatment.

I'm not thinking of the details at this point, but focusing on goals.  
Though in the spirit of making the easy case easy, then yes, for the 
pure mfile case installing all the mfiles in the directory is fine.

> One of these sub-directories is a directory with the octave packaging 
> information.

Yes, if necessary, but if the packaging info sits comfortably in one or 
two files then leave it at that.  Indeed, in the pure mfile case we can 
probably get away with having no packaging information whatsoever. 
Adding the package to the archive will require a description file of 
some sort, though this doesn't necessarily have to be in the package 
directory.

> The goal of this is that existing toolbox of a bunch of m-files can 
> easily be converted to an octave-package..

Yes.

> However, the code I've seen almost always has some sort of 
> sub-directory structure for the code.

I looked at the third entry of every third package on matlab central.  
If this was not intended for installation, I went on to the next.  The 
ones I skipped were gifs, pdfs and doc files.


Single mfile: 3
Mfiles in directory: 2
Mfiles in directory with mex: 1
Mfiles with subdirectories: 1

This isn't enough statistics to support my point, but the web site is 
down.  Better support for isolated mfiles is something to consider.

Here's what I looked at:

Aerospace
        Complete 1970 standard atmosphere
   m-files in directory
Chemistry and Physics
        Unstructured mesh generation
        m-files + compiled dll (no source)
Control systems and modeling/mechanical modeling
        Stepper motor toolbox
        m-files in directory
Games
        sudoku solver
        m-file only
Image processing/compression
        Image compression using wavelets
   m-file only
Optimization
        Particle swarm optimization toolbox
	m-files in directory, plus two subdirectories to be added to path at 
installation
Statistics and probability
        Randraw
        m-file only

> Also when octave gets "@<class>" and "private" directories, any 
> package that includes them is also a special case.

They need not be special cases if they are named "@<class>" and 
"private" or any other name which is predictable by Octave.

> So to me taking all of the package that is directly installed and 
> moving it to an inst/ directory is in fact a better long term 
> compromise as it also addresses the issues of sub-directories that 
> need installing...

The special cases are when there are compiled files, and particularly 
compiled files with supporting libraries that need configure 
information.

> Frankly I don't think there will every be a packaging that is prefect 
> for all uses, and its all a bit of a compromise, but the compromise we 
> have really isn't too bad...

Yes, a package system is better than none.  And having gone through the 
effort of converting octave-forge you have seen much of the 
complexities that will arise.

I'm suggesting that now is the best time to do a retrospective analysis 
before the packaging system enters wide deployment, and consider 
whether the system should be tweaked.  It will be much harder later.

- Paul