Re: "features" problems

[Philip Nienhuis]

Carnë Draug wrote:
> On 20 March 2016 at 19:20, Philip Nienhuis <address@hidden> wrote:
> > Carnë Draug wrote:
> > > [...]
> > >
> > > That solution has another advantage.  PKG_ADD is sourced.  This means that
> > > if anything in PKG_ADD generates a result it will replace local variables
> > > (clearing variables at the end of PKG_ADD does not restore their value).
> >
> >
> > Yes, I know PKG_ADD runs in the current scope; io package's PKG_ADD is
> > careful and cleans up after itself.
>
> It does not restore the original user variables.  If the user had variables
> named:
>
>      libdir spr_status userdir homedir bnam ooopath ii HAVE_JAVA amd64y
>
> they will have been removed after loading the io package.

Sure, your solution in the previous is superior.

> > > The reason for why PKG_ADD behaves like this is that it is meant for
> > > simpler
> > > things, such as registering options.  If you need a complex piece of code,
> > > use a separate function for it and call it from PKG_ADD.
> >
> > That is a good suggestion.
> > But it doesn't change the PKG_ADD location issue which was at the base of
> > this part of the discussion - to wit, why certain octave_config_info output
> > could be required.
>
> It does.  Instead of writing another long email trying explaining this, I
> just did the coding myself.  See bug #47480 and the attached patch.

Must be my ignorance, but in that bug report + linked reports I see 
nothing that negates what I wrote: that pkg.m and/or subsidiaries 
screwed up as regards PKG_* location. A fix for that was indeed needed.
You made that fix, thanks for it and good that it is pushed. Too bad 
that it took such a long time for a solution for those PKG_* issues with 
pkg.m (absolutely no blame on you).

PKG_ADD's location and what io's PKG_ADD is doing are separate issues. 
You fixed the former; my job now is to fix the latter.

> This should drop all your requirements on the paths currently being served
> via octave_config_info.

No, "libdir" is still used. Who knows what other info may be useful or 
even needed in the future.
There's a workaround for "libdir", but not very robust. Getting it from 
Octave itself still looks superior to me.

Philip