Re: Unboxed package manager

[Lynn Winebarger <owinebar@gmail.com>]

On Thu, Mar 23, 2023 at 2:46 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Wed, 22 Mar 2023 18:22:55 -0400
> > Cc: gregory@heytings.org, casouri@gmail.com, emacs-devel@gnu.org
> >
> > On Wed, Mar 22, 2023 at 10:42 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > Why would someone want all 300 of them?  Some of them even contradict
> > > each other, in that they implement similar features in very different
> > > ways.
> >
> > You're correct, many of them do address similar issues and should not
> > be "turned on" simultaneously.  As long as they are well-behaved and
> > able to be switched on and off reliably, though, there's no reason to
> > not have them simultaneously installed and loaded if the user is not
> > dedicated to minimizing resource consumption.
>
> I didn't say people should not be able to do that.  They should, and
> they are.  I just said it isn't a reasonable thing to do, and thus
> doesn't justify our jumping through hoops to cater for it.

Who's asking anyone to jump through hoops to cater to anything?  All
I've done in this thread is ask for any insight on the best way to
derive from package.el, since I only want to extend the
installation/activation/deinstallation behavior, and then respond to
questions about why I would do such a thing.

In fact, I don't think I've asked for any concrete action from emacs
developers beyond not breaking functions that have worked in the past.
I've asked for insight into coding issues, and reported on the results
of my experiments.  I'm not sure how you define "a reasonable thing to
do" without considering evidence from experience when it's available.

> > > > Note I'm just installing
> > > > these packages, not actually loading any of them directly.
> > >
> > > Exactly.  So this is entirely theoretical use case, not a real one.
> >
> > I was just noting that the performance hit comes from merely
> > installing the package (and enlarging the load-path), not from loading
> > it.
>
> And I was just noting that doing such a thing cannot be of any
> practical interest to us, unless it causes severe bugs in Emacs, like
> crashes etc.

No, you were characterizing my efforts as "entirely theoretical",
which they are not.

I have no idea who you are speaking on behalf of when you say "to us".

> I obviously assumed (and I think I even said that explicitly) that the
> directories of those packages shouldn't be added to load-path;

But that is what is done by package.el.

> _instead_, they should be loaded by their explicit file names,
> including leading directories.  _Then_ the problem with load-path will
> not happen.

That wasn't clear at all - it appeared you were referring to the
"require" statements in the "loadall.el" file, since the packages were
not being loaded.

> As for the order of loading packages -- that problem exists anyway,
> and I believe use-package, which is now part of Emacs, is capable of
> making the solution a bit easier.  In any case, solving that is
> basically a one-time issue, when you first install a new package.

So, your definition of "reasonable" implies that packages are only
infrequently changed, or experimented with?

> So what exactly are you asking for?  Is it some change in package.el?
> If so, what change?

See above - I did not ask anyone to *do* anything in terms of coding.
I asked whether anyone more familiar with package.el and elisp than I
am had any better ideas for deriving functionality from package.el
than using "advice".

Lynn