Re: [Gretl-devel] Function packages on Windows: new path permanently added
On Fri, 12 Oct 2018, Sven Schreiber wrote:
Am 12.10.2018 um 01:02 schrieb Allin Cottrell:
> On Thu, 11 Oct 2018, Allin Cottrell wrote:
>
>> On Sat, 6 Oct 2018, Sven Schreiber wrote:
>>
>>> I'm noticing that with the Oct 4th snapshot in the (local) function
>>> package list window a (preliminary) package appears that lives in a
>>> non-standard path.
>>>
>>> This is new I think, because it used to be that one could switch to a
>>> user-specified path, and then only those packages from there was shown.
>>> If one reverted to the standard listing, the non-standard paths would be
>>> forgotten again.
>>>
>>> Is this a bug or a feature?
>> * the user's current working directory.
Ah right, this must be it, my CWD is very likely currently set to that
location.
>
> Another thought, in response to Sven's "bug or feature" question.
>
> The inclusion of the user's working directory in the package
> search path is a feature in the sense of being deliberately
> designed in, but maybe it's a mis-feature (aka bug). Since you
> probably spend more time working with function-package files than
> anyone else, Sven, I'd value your opinion on whether including
> the working directory by default is a help or a hazard. It would
> be easy enough to exclude it.
Good question. For me as a package developer it was actually
useful, because when I debug and recreate the package it is then
(in the CWD) automatically updated within gretl. [...]
OK, then we'll retain that feature.
What's more of an issue for me is the perennial path-searching
problem when including .inp files. My observation (or just
feeling?) is that when I want to include <pathprefix>/helper.inp
from <pathprefix>/main.inp I either have to set the CWD to
<pathprefix> or I have to give absolute, not relative paths. The
first is a nuisance because I often switch projects and/or paths,
the second is also not very elegant I think.
I think I need a full test case to expose the problem you're talking
about, because I'm not seeing it myself (but maybe I'm doing
something different). The design idea is that if you run a script
that sits in some specified directory D (doesn't have to be your
working directory), then any uses of "open" or "include" (for inp
files) within that script will by default look for the requested
file in D. (Other possibilities will be considered if that doesn't
work.)
To be explicit, here's a test case I just ran:
* There's a directory ~/stats/myhre on my system; it contains among
other things the scripts myhre_test.inp and findme.inp, and the
datafile myhre.asc. This directory is not my working directory,
neither is it the current working directory so far as the shell is
concerned. myhre_test.inp includes the lines
open myhre.asc
include findme.inp
(no paths given, just plain basenames).
* via gretlcli: from my home directory I execute
gretlcli -b ~/stats/myhre/myhre_test.inp
and everything is found.
* via gretl (1): from my home directory I execute
gretl ~/stats/myhre/myhre_test.inp
and then run the script from the script editor: again, everything is
found.
* via gretl (2): I start gretl from a desktop menu, use the file
dialog under /Files/Script files to open myhre_test.inp, then run
the script via the Run button. Once again: everything found.
Allin