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

[Alex Dunn <dunn.alex@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

OK.  I'm still not convinced this is good default behavior, but I'll defer
to y'all.  Realgud solved the issue in their case by adding .nosearch files
in the subdirectories, which I didn't realize was an available tool.

On Mon, Aug 1, 2016 at 10:54 AM, Robert Weiner <rsw@gnu.org> wrote:

>
> On Mon, Aug 1, 2016 at 1:19 PM, Alex Dunn <dunn.alex@gmail.com> wrote:
>
>> But there are plenty of other ways to do that.   This makes it a little
>> too easy to override important core libraries, IMO.
>>
>
> ​It should be easy for a site or a user to override default behavior in
> Emacs.  Sometimes this means having modifications loaded prior to
> particular local initialization files running and changing load-path.
> ​
>
>
>>
>> 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.
>>
>
> ​Given all the existing tools that look for Elisp files by filename,
> find-library being just one, it is not a good assumption that the filename
> will always be uniquely identified by adding a directory name.
>
>   Rocky could add 'realgud-' to the beginning of every elisp file in the
>> application,
>>
>
> ​That would be much better and safer and more generally useful.
> ​
>
>
>> 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.
>>
>
> ​There are others.
> ​
>
>
>>
>> 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.
>>
>
> ​Yes, Emacs is a pretty open environment that relies on a lot of trust
> among users and developers.  The community helps keep bad actors from
> acting badly.  Emacs has existed for decades without a major issue like you
> describe and there are very likely good reasons for that.
>
> ​Bob
> ​
> ​
>
>

[-- Attachment #2: Type: text/html, Size: 5214 bytes --]