emacs-devel
[Top][All Lists]
Advanced

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

Re: why is site-lisp placed before the default load path?


From: Alex Dunn
Subject: Re: why is site-lisp placed before the default load path?
Date: Mon, 1 Aug 2016 10:19:12 -0700

It's precisely so that users could have their local versions loaded in
> preference to the bundled ones, I think.

But there are plenty of other ways to do that.   This makes it a little too easy to override important core libraries, IMO.  

realgud is just an example.  It uses names like js.el and info.el because they are supposed to be loaded via `load-relative`, rather than required directly, but subdirs.el placing them at the front of the load path is what's causing trouble.  Rocky could add 'realgud-' to the beginning of every elisp file in the application, but `load-relative` and the directory structure makes that unnecessary.

You might argue that every elisp file in an application should be named to avoid conflicts with core libraries, but the only reason I see for that requirement is the current ordering of the load path.

And beyond the inconvenience caused by programs using `load-relative`, or programs just accidentally using the same name as a core library, it seems possible that a malicious developer could tuck their own `url.el` into an otherwise innocuous package and cause some mayhem.

On Mon, Aug 1, 2016 at 9:39 AM, Eli Zaretskii <address@hidden> wrote:
> From: Alex Dunn <address@hidden>
> Date: Mon, 1 Aug 2016 09:24:34 -0700
>
> Right now, `init_lread` in lread.c creates the initial load path by concatenating PATH_SITELOADSEARCH and
> PATH_LOADSEARCH, in that order. Since subdirs.el searches recursively and adds everything to the
> load-path, if I install (for example), realgud into site-lisp, things break because a number of Emacs' own
> libraries are shadowed by realgud's language and utility modules:
> - https://github.com/realgud/realgud/tree/master/realgud/common
> - https://github.com/realgud/realgud/tree/master/realgud/lang
>
> Looking through the code history, this order has been deliberately maintained for well over a decade, but
> what's the reason for letting core libraries be overridden like this?

It's precisely so that users could have their local versions loaded in
preference to the bundled ones, I think.

If realgud somehow causes trouble due to this, the problem should be
solved there, IMO.


reply via email to

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