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

[Carnë Draug]

On 24 February 2014 16:57, Julien Bect <address@hidden> wrote:
> On 24/02/2014 17:20, Carnë Draug wrote:
>>>
>>> Could you please try to step through stk_init.m to understand why it is
>>> called several times ?
>>
>> I found the problem. the problem is when stk_init calls clear which is
>> modified on my side to, among other things, reload packages. Because
>> of this, it gets stuck into a loop reloading the stk package.
>>
>> Reverting my local changes to clear, I could load it correctly. While
>> you remove most of the temporary variables, it seems your script
>> forgets two of them "STK_SKIP_BUILDMEX" and "mole_dir"
>
>
> This is now fixed, thank you.
>
>>>> Also, why do you have the functions split into multiple directories?
>>>> If you are already creating the package with a script, there's no need
>>>> for organization, you might as well place all the m files into a
>>>> single directory. This will also make it simpler for you, and will be
>>>> less prone to bugs when adding and removing to the search path.
>>>
>>> As a user, I prefer when I can browse the source tree and understand from
>>> its structure how the toolbox/package/module/... is organized. So, yes, I
>>> know that I could put everything into a single directory, but I would
>>> really
>>> prefer to keep the original layout if possible (I see that the LTFAT
>>> package
>>> has subdirectories, for instance, so it shouldn't be a problem).
>>>
>>> Plus, the packaging script would be more delicate to write, since not
>>> everything must be flattened out (for instance, we have private
>>> subdirectories, class subdirectories, and even class subdirectories that
>>> contain private subdirectories that contain MEX-files...).
>>>
>>> Of course, if it turns out that this is the only to make it work, I will
>>> do
>>> that.
>>
>> I know other packages do it and they all have that reason. I still
>> always advise against it. Managing path manually is a pain and likely
>> to cause unexpected problems. And if Octave ever changes how it
>> manages packages internally, it will suddenly break. You are relying
>> on things which, albeit stable, are undocumented and not meant to be
>> used.
>
>
> Well, I certainly don't want things to "break suddenly" if I can avoid it...
>
> Which undocumented feature am I relying on, exactly ?

You are assuming that the current working directory during pre_install
is the directory of your uncompressed package, and that pkg will
maintain whatever structure you have inside the inst/ for
installation. I believe these should be good expectations though, I'm
just reminding you that this is undocumented.

And really, it appears to me that for the purpose of organization,
you're having not only more work but also increasing the chances of
problems. It's sacrificing stability and simplicity for the sake of? A
developer will use your repository, a user that wants to inspect a
specific function will know what function it is looking for, and will
be able to find it easily even if they are all in the same directory.

This also causes other trouble. For example, I'll guess this is what
causing you to add isoctave and ismatlab to the path, that the common
diretory is actually what you would like to be the private functions
shared among the whole package. Other packages aim at Matlab
compatibility and may have their own version of this functions. If
each packages adds their own version to the path.... You also have
commonsize() and graphicstoolkit(). Which one will your package use
when multiple packages are loaded with this functions? If you had
everything on the same directory, you can place them all under a
private directory.

Anyway, this is just my opinion. Different people have different
methodologies and after all, it's you who will be developing the STK
package. What's simpler for me may not be for you.

>> This is what I get when I install the package
>> http://bpaste.net/show/WaA1RPB6zuIYx0wwXbGB
>
>
> I have never seen the first warning that you get (concerning
> stk_dist_matrixx.mex). Do you know what it means ?

Some issue about not unloading the package before uninstalling? You
should be able to reproduce this way:

pkg install stk-2.2.tar.gz
pkg load stk
pkg uninstall stk
pkg install stk-2.2.tar.gz

This may be an Octave bug though.

> Concerning the other three warnings : I know, I can see them too, but as I
> told you the warning is inaccurate since I'm not acutally adding these to
> the path. Anyway, I will simply remove them if they are not needed, which
> should make the warnings disappear. Is it OK if I delete them from inst in
> the pre_install script ?

Should be fine. But isn't it easier to simply not add them to the
package? Why risk it have it done multiple time under many different
conditions during installation, when it can be done only once during
package release in a controlled environment?

>> Also, the way you move the mex files into the same directory as m
>> files is not recommended. Downstream packages are unlikely to be happy
>> about it, since architecture dependent files are supposed to be kept
>> separated.
>
> I didn't know that... How can I separate architecture dependent-files from
> architecture independent files when i have MEX-files inside private
> directories ? (The same question would be relevant for MEX-files in class
> directories, but I don't have any of them.)

You can't. The convention is to name them __foo__. This is also what
Octave core does.

Carnë