Re: globally installed packages vs. relocatable Octave

[c.]

On 7 Nov 2014, at 10:14, c. <address@hidden> wrote:

> 
> On 6 Nov 2014, at 19:25, John W. Eaton <address@hidden> wrote:
> 
>> Is it necessary to allow the global prefix to be modified, or would it
>> be OK to simply expect that globally installed packages are located in
>> a directory under OCTAVE_HOME? 
> 
> I am not sure that would work if we intend to make a relocatable .app
> bundle for OSX.
> 
> an app bundle is just a folder you can move around where you like through
> the finder GUI which contains all executables, libraries and data files
> required for the application to run.
> 
> How would you change the value of OCTAVE_HOME when the the bundle is moved?
> 
> c.

One thing that I really don't understand is why we 
really need to make a distinction of local and global 
packages.

Can't we just have a list of directories containing package trees listed in 
order of  
presedence in a configurable variable similar to "load_path"?

for adding a set of precompiled packages we could the just do:

pkg addpath /path/to/directory

for installation we could just have an option like:

pkg install -d /path/to/directory

if the default path wer set to ~/.octave for normal users and
to something in OCTAVE_HOME for superuser this would essentially work the
same as the current implementation ...

I am not sure a package database is really needed either but, if it is,
it could contain paths relative to /path/to/directory so distributing
a set of precompiled packages would, in most case(*), take only the following 
steps:

octave --eval "pkg install -d ~/my_package_tree -forge package1 package2 ..."
cd ~
tar czf my_package_tree.tgz my_package_tree

does this approach make sense?
c.

(*) for packages depending on external libraries that are not already linked
to the octave binary things would be only slightly more complicated.