Re: Requirements for releasing the STK toolbox as an Octave forge package ?

[Julien Bect]

Le 11/02/2014 14:06, Carnë Draug a écrit :
> On 10 February 2014 11:07, Julien Bect <address@hidden> wrote:
> > STK is meant to work both with Octave and with Matlab and, for that 
> > reason, its primary repository is not organised as an Octave package. 
> > I would like to keep the current organisation, which allows to use 
> > the toolbox "in place" both from Octave and from Matlab, and from 
> > there generate for each release an Octave package for Octave users 
> > that prefer to install it using pkg. Plus, we want like to keep full 
> > control over the STK as a Sourceforge project (description, front 
> > page, developpers, screenshots, news, etc.). 
> This is perfectly fine with us. However, we do need to keep a clone of 
> the repository for ourselves with everything ready to prepare a 
> release. This is not the unpacked tarball, can be a repository with a 
> very different structure (like what you have now), with the script 
> used to create a tarball of the package that is released.
>
> I noticed you are using svn. If you were using mercurial or git, the 
> distributed would be more natural. It is still possible to do it, it's 
> just less natural. Would probably be easier if you converted your 
> repository to one of them (in Octave we have a preference over 
> mercurial) and I can help you with that if you pop in #octave one of 
> these days.

I already read STK's repository with hgsubversion on a daily basis... I 
will consider moving completely to hg, since Sourceforge allows it (have 
to check with my co-maintainer, though).

> > > > I have started to write a Python script that prepares a tar.gz with 
> > > > all the required files for an Octave package (DESCRIPTION, PKG_ADD, 
> > > > PKG_DEL and so on). It is not finished yet, but already produces a 
> > > > valid package that can be installed using Octave's pkg command : 
> > > > http://sourceforge.net/p/kriging/code/HEAD/tree/trunk/admin/make_octave_package.py 
> > >
> > > I think that is at least the third such script that has been created, 
> > Well, it is by no means meant to be a generic script for doing this, 
> > just something ad hoc that can process the specific file/folder 
> > structure of STK and convert it to an Octave package. But if there 
> > are other scripts out there from which I could take inspiration, I 
> > would be glad to have some pointers. 
> I have written such scripts before. Each project places things in 
> different places so it's not really feasible to write one for all 
> cases (a template that can be adjusted to each case would be a useful 
> thing but that's a completely different issue). I very much support 
> this type of distribution for projects that want to create packages 
> for both Octave and Matlab

Fine. We'll keep it that way, then.


> > > > Would there be any other requirement for our toolbox to be 
> > > > distributed as an octave forge package ? 
> > > maybe you could also check whether your package has 
> > > conflicts/overlaps/redundancies with respect to other existing 
> > > packages. 
> > optiminterp does something that looks very much like (noiseless) 
> > kriging, although I haven't looked at the details. splines also has 
> > connections with kriging, since for examples spline smoothing with 
> > thin-plate splines can be seen as kriging with a certain 
> > (generalized) covariance function 
> We can't distribute the package if any of its function has a 
> conflicting name with other packages (that doesn't seem to be the case 
> with all your functions starting with stk_).

Of course. As you observe, there should be no such problem since most of 
our functions are prefixed with stk_. Anyway, should any such problem 
arise, we would fix it.


> I saw that your package is dependent on Matlab's parallel package and 
> recommends the optimization package. We also have those 2 packages but 
> I'm not sure if they have implemented what you require from them.

No, there is no such dependency for Octave. These are for use with Matlab.

parallel : Our toolbox currently supports some parallelization under 
Matlab only (with Mathworks' Parallel Computing Toolbox). But the 
toolbox has been designed to be easily extensible to other 
"parallelization engines" and making it work with Octave packages () is 
definitely on my TODO list.

optimization : Under Octave we use sqp, which is in Octave core. Under 
Matlab we use either fmincon (it the optimization toolbox is available) 
or fminsearch (otherwise). Later, this part of STK will be made more 
configurable, in order to support the use of various optimizers 
(provided that there are detected at runtime).

In short : no dependency problem to solve. In fact, at each release of 
STK, I check that the entire test suite runs on various releases of 
Octave (3.2.4, 3.6.4 and the latest development version, typically).


> Basically the basic requirements to be distributed with Octave are:
> * installable in Octave via pkg

OK, the tar.gz that is produced by my packaging script already works.


> * clone of the repository with everything required to prepare the 
> release in our side as well

I think that I will move to mercurial for our Sourceforge repo. There 
should be no problem, then, should it ?


> * not dependent in any non-free software
> * released under a GPL compatible license Carnë

This is already true.