[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: globally installed packages vs. relocatable Octave

From: c.
Subject: Re: globally installed packages vs. relocatable Octave
Date: Fri, 7 Nov 2014 11:10:46 +0100

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 

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 

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?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]