octave-maintainers
[Top][All Lists]
Advanced

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

Re: Autoloading of toolboxes?


From: David Bateman
Subject: Re: Autoloading of toolboxes?
Date: Tue, 30 Jan 2007 10:23:18 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Bill Denney wrote:
> David Bateman wrote:
>> However, ideally there should be some means to avoid autoloading
>> particularly of globally installed packages...
> How does this sound:
>
> * There is a file in the package directory that defines if the package
> is supposed to be auto-loaded as I previously described.
That wouldn't be too hard to do.. However for convenience Whether to
autoload the package by default should be in the DESCRIPTION file, and
should be able to be overloaded at the time of installation by the
installer.

> * If there is a global package directory and a local package directory
> with the same name, absence or presence of the file in the local
> directory overrides the global package directory's file.

The local package should always take precedence, as a particular user
installed it for their own use. However, as it stands, I can see how
there might be a local and global version of a package with a scenario like

1) User 1 installs package locally, then logs out
2) User 2 installs package globally
3) User 1 logs in and find themselves with a local and global version of
the same package

Unfortunately, looking at pkg.m it doesn't treat this case as
pkg.m(installed_packages) returns both versions of the package, with the
local version first.. Therefore the global version will override the
local version as it will be added on the path at the head of the path
after the local version...

I think we have to have the attached patch to address this issue. This
patch makes the list of installed packages unique with the local
packages taking precedence and so the pkg("load",...) command will only
load the local package in the above case

>
> To me that a) leaves it in user control, b) shouldn't be too hard to
> implement, and c) doesn't seem too fragile (assuming that packages
> just use their package name as the directory name since that won't
> change between versions).
I think it is necessary, and will do something for it along these lines...

Regards
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

*** ./scripts/pkg/pkg.m.orig29  2007-01-30 10:17:04.716505759 +0100
--- ./scripts/pkg/pkg.m 2007-01-30 10:15:32.703402761 +0100
***************
*** 1094,1100 ****
          global_packages = {};
      end_try_catch
      installed_packages = {local_packages{:} global_packages{:}};        
!     
      ## Should we return something?
      if (nargout == 2)
          out1 = local_packages;
--- 1094,1120 ----
          global_packages = {};
      end_try_catch
      installed_packages = {local_packages{:} global_packages{:}};        
! 
!     ## Eliminate duplicates in the installed package list.
!     ## Locally installed packages take precedence
!     dup = [];
!     for i=1:length(installed_packages)
!       if (find(dup,i))
!       continue;
!       endif
!       for j=(i+1):length(installed_packages)
!         if (find(dup,j))
!         continue;
!         endif
!         if (strcmp(installed_packages{i}.name,installed_packages{j}.name))
!         dup = [dup, j];
!       endif
!       endfor
!     endfor
!     if (! isempty(dup))
!       installed_packages(dup) = [];
!     endif  
!   
      ## Should we return something?
      if (nargout == 2)
          out1 = local_packages;

reply via email to

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