Re: Proposal for 'package-isolate' command

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: thievol@posteo.net,  emacs-devel@gnu.org
>> Date: Tue, 15 Aug 2023 19:52:32 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Seems strange to me to have a command to start another Emacs.  Why not
>> > implement this as a command-line option instead?  That would be
>> > consistent with the several options we already have, like -q, -Q, -D,
>> > which already contrl what happens at startup.
>> 
>> Mainly because this wouldn't support a completing-read interface, that
>> simplifies prompting the user for a set of packages.
>
> Shells can complete as well, right?  And once you typed the command
> once, shells have features to help you invoke commands from history,
> so you won't need to retype it more than once.

Each shell requires individual completion support, and figuring out what
packages are installed outside of Emacs to ensure input like
"magit-3.3.0,corfu-0.37" is well formed, seems too much work to me.

What would be reasonable, might be a function that could be invoked from
batch mode.

  emacs -Q --batch -f package-isolate-batch magit corfu

>> But perhaps the bulk of this command could be implemented as a CLI
>> option, that this command could wrap?
>
> Maybe.  But again, it's strange to have to launch another process from
> Emacs for such a simple functionality.  And if the number of packages
> to load is large, typing them manually would be annoying anyway, so
> people will probably store the list in a file or something?  So maybe
> we should allow specifying a file with the list of packages as well?

I don't know how this package would be used, but the way I imagine it is
that a package maintainer asks the user to run

  M-x package-isolate RET foo-1.2.3 RET

with only a few packages, to make the reproduction of bugs easier, as
is the case with Helm, which is what prompted this tangent.

>> >> +          (make-symbolic-link real link t)
>> >
>> > Using symbolic links makes the program less portable, so it is best to
>> > avoid them.
>> 
>> The reason I used them here, instead of just adding the directories
>> under ~/.config/emacs/elpa/ is that startup.el issues a warning along
>> the lines of
>> 
>>   Your `load-path' seems to contain your `user-emacs-directory' ...
>> 
>> My previous patch actually included the code that suppresses all
>> warnings during initialisation, so I've removed this hack.
>
> I don't understand how this is different from a "normal" startup of
> Emacs with all the packages.  Here, you just want to load part of the
> packages that are loaded normally, so why does this warning pop up in
> this case, but not when Emacs starts "normally"?  I'm probably missing
> something.

The point is moot anyway, since the approach that Thierry proposed
circumvents the issue to begin with.