octaverc and version in path?

[Ben Abbott]

On Dec 31, 2007, at 12:08 AM, Thomas Treichl wrote:

> Ben Abbott schrieb:
>> On Dec 30, 2007, at 10:41 PM, Thomas Treichl wrote:
>>>> Ben Abbott schrieb:
>>>>
>>>>> On Dec 30, 2007, at 6:03 AM, Thomas Treichl wrote:
>>>>>
>>>>> Ben Abbott schrieb:
>>>>>> Thomas,
>>>>>> Thanks for the reply. I've  not used genpath before, but if I  
>>>>>> understand its functionality, won't that solution simply add  
>>>>>> all directories that lie within Users/dushanm/Octave?
>>>>>
>>>>> I'm not very quick right now in reading and answering emails.  
>>>>> That's why I've overlooked the end of the last thread.
>>>>>
>>>>> Right Ben, all subdirectories are added too...
>>>>>
>>>>>> I'm not so organized. My octave directories are scattered and  
>>>>>> often contain directories I don't want in the path.
>>>>>
>>>>> There is another nice command 'rmpath' to delete one or more  
>>>>> entries in the path list.
>>>>>
>>>>> help rmpath
>>>>>
>>>>> gives more info about how to use it.
>>>>>
>>>>>> By chance did you look over my email where I suggested  
>>>>>> a .octaverc resembling that below
>>>>>> ## Begin savepath auto-created section, do not edit
>>>>>> path ([pathdef,pathsep,'/Users/bpabbott']);
>>>>>> ## End savepath auto-created section
>>>>>
>>>>> Seems to work too, sure, an equivalent implementation would be
>>>>>
>>>>> addpath ("/Users/bpabbott");
>>>>>
>>>>> Thomas
>>>>
>>>> Thomas,
>>>>
>>>> I think there is some confusion, perhaps it began on my end?
>>>>
>>>> In any event, the problem I've been looking at occurs when  
>>>> savepath.m is run and then octave is updated to a new version.
>>>>
>>>> For example, if savepath.m is run from octave 2.9.15(?), and  
>>>> octave is updated (say to 3.0.0), then when octave 3.0.0 is run  
>>>> the working path is replaced by the that of 2.9.15. In the event  
>>>> that the 2.9.15 version has been deleted, the result is a  
>>>> nonfunctional octave. If 2.9.15 is not deleted, octave 3.0.0 will  
>>>> still try to use the m-files and oct-files of the 2.9.15  
>>>> version ... perhaps the result would be partially functional.
>>>>
>>>> So what I was hoping to discuss were approaches to (1) update  
>>>> without worries of loading a non-functional path from .octaverc,  
>>>> and (2) would it be possible for .octaverc to support multiple  
>>>> versions of octave simultaneously?
>>>>
>>>> There are many approaches to reconciling this. I decided to try  
>>>> to limit myself to savepath.m since it is responsible for adding  
>>>> the path information to .octaverc.
>>>>
>>>> After some thought on how savepath.m might be modified to avoid  
>>>> including version specific paths, I decided to try extract the  
>>>> portions of that path that are not present in the pathdef (let's  
>>>> call that portion userpath), and then store the result  
>>>> in .octaverc as
>>>>
>>>> path ([pathdef, pathsep, userpath]);
>>>>
>>>> Then if a change to a new version of octave occurs, octave will  
>>>> load a functioning path. I have completed such a modification to  
>>>> savepath.m and it appears to work as expected.
>>>>
>>>> One unfortunate feature of this approach is that the resulting  
>>>> path does not respect the "-end" and "-begin" options of addpath().
>>>>
>>>> Thoughts?
>>>
>>> Everything makes sense to me that you have found out. I would say  
>>> you send a copy of your email (the part above) and your code  
>>> modifications that you've implemented to the discussion that has  
>>> been started at the maintainers-list.
>>>
>>> The only thing that I'm currently thinking about: Should  
>>> 'savepath' really write anything directly into the .octaverc file  
>>> if no input argument is given?
>>>
>>> Thomas
>> What do you propose, if no input is given?
>> Also, how is a new (in some cases expeirenced) user to know about  
>> ~/.octaverc and its intended function?
>
> Right, so my thoughts about this are that an experienced user does  
> know about .octaverc and at least does know what to do if he called  
> (expected or not) 'savepath()' without input argument and modified  
> his .octaverc file. Further, if the nargin==0 option wouldn't be  
> there right now then the experienced user could easily use
>
>  savepath ("~/.octaverc");
>
> An unexperienced user calls 'savepath()' and does not see anything  
> happen on screen. In real he modified his .octaverc file. He  
> (platform independent) upgrades to a newer version of Octave and  
> nothing does work anymore (because of the version specific path  
> names). However, version specific path names seem to have much  
> higher priority to me.
>
> I summarize my thoughts here: Per default (eg. without any input  
> argument) an Octave function should not modify any of the files on a  
> disc as long as it is not absolutely clear and/or absolutely  
> necessary. Better throw an error here with the 'savepath' function  
> if nargin==0.

ok. One point, the patch I submitted respects the version specifics.

Meaning that you can run different versions of Octave and all should  
work (fingers-crossd) as expected.

Regarding the silent change to .octaverc, we could add a warning when  
nargin==0 and  still save the current working path is ~/.octaverc.

Would that be satisfactory?

Ben