Re: Proposal for 'package-isolate' command

[Philip Kaludercic <philipk@posteo.net>]

Thierry Volpiatto <thievol@posteo.net> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Thierry Volpiatto <thievol@posteo.net> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>>> No don't worry, helm will work in any cases, thanks.
>>>>>
>>>>> OK, in that case I'd prefer to keep it the way it is.
>>>>
>>>> Ok, fair enough.
>>>>
>>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>>
>>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>>
>>>>> It might not be the best example, but my package autocrypt generates a
>>>>> file in the `user-emacs-directory'.  If we don't use --init-directory,
>>>>> the existing file would be re-used.
>>>>
>>>> Ok, for such case it is easy to either rename the file temporarily to
>>>> foo_ori or foo_save or to set the variable handling the file (generally
>>>> it is not harcoded) to something else. But another issue is if your
>>>> isolated package needs the history file or tramp file or whatever file
>>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>>> I still think it is more handy to reuse user-emacs-directory and its
>>>> elpa directory where the packages are already installed.
>>>
>>> How about this patch, that will use a temporary directory when
>>> `package-isolate' is invoked with a prefix argument (not sure what the
>>> default should be, I guess reusing `user-emacs-directory' is less
>>> surprising):
>>
>> However it is not working properly:
>>
>> Tried to isolate two packages, osm and w3m, and osm use compat as
>> dependency:
>>
>> Unable to activate package ‘osm’.
>> Required package ‘compat-29.1.4.0’ is unavailable
>
> Forget it, it is working properly, just forget you had modified
> package--dependencies as well.
> Sorry for the noise.

It was either that or a new function had to be added, not sure which
approach is worse.  The current implementation seems to have been
hastily added by Lars last year, and it is a bit regrettable in
retrospect.  It would be possible to modify my change, and have the
function always return package-desc objects, since the function is only
used in one other spot in another part of the file.  While there might
be others (packages or individuals) that depend on the function behaving
the way it does, but on the other hand, convention designates it as
being an "internal" function.

Thierry Volpiatto <thievol@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Hello Philip,
>>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Thierry Volpiatto <thievol@posteo.net> writes:
>>>>
>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>
>>>>>>> No don't worry, helm will work in any cases, thanks.
>>>>>>
>>>>>> OK, in that case I'd prefer to keep it the way it is.
>>>>>
>>>>> Ok, fair enough.
>>>>>
>>>>>>>> Mainly to avoid issues with packages that might place files in the
>>>>>>>> configuration directory, which might hinder the reproduction of bugs.
>>>>>>>
>>>>>>> Hmm, maybe, I don't have an example in mind though.
>>>>>>
>>>>>> It might not be the best example, but my package autocrypt generates a
>>>>>> file in the `user-emacs-directory'.  If we don't use --init-directory,
>>>>>> the existing file would be re-used.
>>>>>
>>>>> Ok, for such case it is easy to either rename the file temporarily to
>>>>> foo_ori or foo_save or to set the variable handling the file (generally
>>>>> it is not harcoded) to something else. But another issue is if your
>>>>> isolated package needs the history file or tramp file or whatever file
>>>>> ~/.emacs.d is handling; e.g. a package providing completion on history.
>>>>> I still think it is more handy to reuse user-emacs-directory and its
>>>>> elpa directory where the packages are already installed.
>>>>
>>>> How about this patch, that will use a temporary directory when
>>>> `package-isolate' is invoked with a prefix argument (not sure what the
>>>> default should be, I guess reusing `user-emacs-directory' is less
>>>> surprising):
>>>
>>> Yes.
>>>
>>> Isn't these two loop the same? (save one loop)
>>
>> No, because that assumes that we are only interested in the first
>> package descriptor in every package--alist entry, while there might be
>> multiple.
>
> Ah ok.
>
>>>     (cl-loop for p in (cl-loop for p in (package--alist) append (cdr p))
>>>     	 unless (package-built-in-p p)
>>
>> Also, do we want this or wouldn't it be useful to be able to force a
>> built-in package being loaded?
>
> Some packages seems to require a specific version of a package for their
> dependency e.g. seq, by excluding it the package may not work correctly,
> this is my understanding but I may be wrong. Also perhaps the package
> e.g. seq is selected later when computing dependencies but maybe user
> wants to select a particular version manually in the first place?

The current algorithm should pick the first package in the package alist
that satisfies the necessary dependencies.  Perhaps that should be
re-thought or the selection should be more clever, e.g. if the user
explicitly specifies a dependency with a version, then it should be
preferred to whatever other dependency might be determined, at the
possible expense of triggering runtime bugs.