Proposal for 'package-isolate' command

[Philip Kaludercic]

Thierry Volpiatto <thievol@posteo.net> writes:

>>>> I don't know much about Helm, but does it not support CRM?
>>>
>>> It does, but this is a much better interface than CRM.
>>
>> I don't think it makes sense to add support like this in the core,
>
> Perhaps yes. However it doesn't requires helm:
>
>      (let ((helm-comp-read-use-marked t))
>         (if (and (boundp 'helm-mode) helm-mode)
>             (completing-read ...)
>           (completing-read-multiple ...)
>
>> but is there something we should keep in mind to not hinder
>> integration with Helm?
>
> 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.


[...]

>>>>>       (let* ((name (concat "package-isolate-" (mapconcat #'identity
>>>>>                                                          packages ",")))
>>>>
>>>> This doesn't work, because the above returns a string, not a list of 
>>>> strings.
>>>
>>> No, it works, the above returns a list of strings (the completing-read
>>> allows marking and returns always a list).
>>
>> Not in my case, I got a type error.
>
> Yes, because the let-bounded var had no effect in your case, otherwise
> when helm is installed and helm-mode enabled the completing-read will
> always return a list.

Right, but that is the issue here, because using completing-read,
especially in the core, shouldn't make any assumptions like that.  In
the end this boils down to the fact that completing-read and co. are a
over-burned interface...

[...]

>>>> It seems to me, that for a proper isolated environment, we should add
>>>> a --init-directory option.
>>>
>>> Why as long as other directories in elpa are not in load-path?
>>
>> 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.

>> Upon reflection, my approach might have an issue if the user wishes to
>> install a package, for the sake of testing within the isolated
>> environment.
>
> Yes, one more reason to use the original elpa dir ;-)

No, because in that case the package installed in the temporary
environment would be retained in the original elpa/ directory, which I
think we /don't/ want.

>> Perhaps it would be better to set `package-directory-list' instead?
>
> Don't know yet.

Even better, I have added all directories that
`package-load-all-descriptors' would load to `package-directory-list',
which should be more robust.

>> Also, would it make sense to have some visual/textual indication that
>> this is a testing environment?  Perhaps the *scratch* buffer string
>> could be modified or the default background colour could be set to
>> something else.
>
> No particular opinions about this.

I guess this is too controversial.  Perhaps just adjusting
`frame-title-format' would be enough.


[...]