Re: Unboxed package manager

[Lynn Winebarger]

On Tue, Mar 21, 2023 at 1:29 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Tue, 21 Mar 2023 14:20:41 +0000
> > From: Gregory Heytings <gregory@heytings.org>
> > cc: owinebar@gmail.com, casouri@gmail.com, emacs-devel@gnu.org
> >
> > >> I'm not surprised, but I wonder whether it's possible to do better.
> > >
> > > Yes: load each package with an explicit absolute file name, without
> > > relying on load-path search.

That is not guaranteed to work unless you are certain the required
files are loaded in the correct order and don't use any "load"
expressions themselves.

> > Of course 😉  But by "doing better" I meant "to improve the way Emacs uses
> > load-path in such cases".
>
> Why try to solve a problem if it can be avoided altogether?
>
> > Likely with some kind of cache.
>
> A cache will not necessarily help, and you will pay the price of
> searching it at least once.  It should be clear that enlarging the
> length of load-path is not scalable, unless we make it a hash-table of
> sorts.  And I'm not sure we want this kind of complexity for such a
> hilariously marginal use case.

Maybe 2000+ is marginal (today), but let's say someone just installs
the 300 packages available on gnu elpa.  Note I'm just installing
these packages, not actually loading any of them directly. Assuming
the time cost is linear in the number of prepended paths, that would
cause load time for system libraries, whether at startup or by
autoloading, to increase to ~18s, or increase by a factor of 4, even
if those packages are only available for autoloading and not actually
loaded.

Although if you look at something like doomemacs, people go to a lot
of trouble to make packages available on their system without paying
this overhead.  The simplest approach is probably just to avoid
increasing the size of the load path when it's not really necessary.

Lynn