Re: Adding to the end of the load path

[Andreas Rottmann <a.rottmann@gmx.at>]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Sorry for the delay.
>
> Andreas Rottmann <a.rottmann@gmx.at> skribis:
>
>> Ian Price <ianprice90@googlemail.com> writes:
>
> [...]
>
>>> Andreas Rottmann suggested something similar in February[1].
>>>
>> I've attached a patch implementing that suggestion, FWIW.
>>
>>> I don't have any concrete proposals better than what Andreas has
>>> suggested, but I felt I should make this post to the list, lest Mark and
>>> I forget.
>>>
>>
>> [...]
>>
>>> 1. http://lists.gnu.org/archive/html/guile-devel/2012-02/msg00038.html
>
> Like Mark, I’m not comfortable with changing the meaning of the empty
> string in the load path, and the behavior of ‘%parse-path’.
>
I agree to that -- there's quite a risk breaking existing setups this
way.

> I pretty much like Mark’s suggestion of using ‘...’ as a special marker,
> even though that’s a valid file name.
>
Well, there's a workaround -- specifying "./..." as an "escape sequence"
for "..." if you really need to have a three-dot relative directory in
the path.

> How would that work for you?
>
I would like the approach using separate _SUFFIX variables better, as it
doesn't have this special case.  While I don't think the special case
will be a problem for a user setting the environment variables
themselves, if you want to set them programatically, you now have to
consider treat "..." specially, escaping it like mentioned above, to be
general.  However, I can live with that, but maybe we can have it both
ways:

- Add the _SUFFIX environment variables, making it clear in the docs
  that they are supported only from Guile 2.0.7 onward.

- Additonally, add "..." as a special marker, but mention it is just
  provided to support Guile < 2.0.7, and should not be used in code that
  needs to depend on Guile 2.0.7 or newer for other reasons
  (e.g. reliance on another added feature or significant bugfix).

I'm not sure how the deprecation strategy is employed exactly, but we
could mark the "..." feature as deprecated right away, or at least in
master, and remove it in 2.2 or 2.4. This would also kind of lift the
"burden" from programs manipulating *_LOAD_PATH programatically, as they
can still be "general" wrt. _undeprecated_ features.  Opinions?

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>