Re: Changes to make in elpa-packages file for nongnu elpa

[Philip Kaludercic]

Thierry Volpiatto <thievol@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Thierry Volpiatto <thievol@posteo.net> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>>>>> It is used specially for reproducing bugs in a clean environment, see 
>>>>>>>> it
>>>>>>>> as emacs -Q for Emacs when reporting bugs. This script starts Emacs -Q
>>>>>>>> with only Helm loaded, this ensure the bug if one comes from Helm and
>>>>>>>> not another package. This is important especially nowaday people are
>>>>>>>> using "Emacs distribution" with the world list of packages installed.
>>>>>>>> Apart that the script is useful to quickly launch Emacs with helm, one
>>>>>>>> can use it from the Helm directory or symlinked to e.g. ~/bin. 
>>>>>>>
>>>>>>> I see.  In that case is there any reason you implement this as a shell
>>>>>>> script?
>>>>>>
>>>>>> Well when I wrote the script, packages where not existing and from
>>>>>> outside emacs it is actually the only way to run a package isolated.
>>>>>>
>>>>>>> (It might be interesting to provide something like this for
>>>>>>> package.el, to test packages in a generic way.)
>>>>>>
>>>>>> Yes, this would be interesting, it would be something like this:
>>>>>>
>>>>>> Emacs -Q
>>>>>> M-x <A command that run a package alone, isolated from other
>>>>>> packages nuisances>
>>>>>
>>>>> I was actually thinking of a command like
>>>>>
>>>>> M-x package-isolate RET foo,bar,baz RET
>>>>>
>>>>> and a new instance of Emacs using -Q is spun up, with all the packages
>>>>> you have listed loaded, and nothing else... Sounds like a fun little
>>>>> weekend project ;^)
>>>>
>>>> Here is my first attempt at providing this kind of a command.  Any
>>>> comments?
>>>
>>> Why not reusing package.el functions?
>>> Why do you want to start in an isolated elpa directory?
>>> Isn't something like this suffice? (just missing to fallback to CRM when
>>> helm is not available)
>>
>> 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, but
is there something we should keep in mind to not hinder integration with
Helm?

>>>     (defun package-isolate (packages)
>>>       "Start an uncustomised Emacs and only load a set of PACKAGES."
>>>       (interactive
>>>        (list (let ((helm-comp-read-use-marked t))
>>>                (completing-read "Packages: " (mapcar #'car 
>>> (package--alist))))))
>>
>> This doesn't allow selecting specific package versions, in case multiple
>> are installed (which might easily happen if you use package-vc).  I
>> stole the code in my patch from package-delete, and I guess it would be
>> possible to generalise it into a utility function.
>
> Ok, I don't know much how package-vc works.

I can have a classical tarball package installed next to a VC package,
just like you can have a built-in package or a system package, and it
makes sense to be able to decide which one to isolate.

>>>       (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.

>>>              (deps (cl-loop for p in packages
>>>                             for sym = (intern p)
>>>                             append (package--dependencies sym))))
>>>         (apply #'start-process (concat "*" name "*") nil
>>>                (list (file-truename (expand-file-name invocation-name 
>>> invocation-directory))
>>>                      "--quick" "--debug-init"
>>>                      (format "--eval=%S"
>>>                              `(progn
>>>                                (require 'warnings)
>>>                                (add-to-list 'warning-suppress-log-types 
>>> 'initialization)
>>>                                (require 'package)
>>>                                (setq package-load-list
>>>                                 ',(append (mapcar (lambda (p) (list (intern 
>>> p) t)) packages)
>>>                                           (mapcar (lambda (p) (list p t)) 
>>> deps)))
>>>                                (package-initialize)))))))
>>
>> This is actually a good idea, assuming there are no issues with lexical
>> scoping that might arise from --eval.  I didn't think of using
>> package-load-list here, but it seems that this only works if we don't
>> add --init-directory, because otherwise the elpa/ directory is not
>> populated.
>
> Yes of course.
>
>> 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.

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.  Perhaps it would be better to set `package-directory-list'
instead?

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.

>> This is easy to fix though, we just need to specify `package-user-dir'
>> at startup.  Here is my updated patch, merging our approaches:
>>
>> [2. text/x-diff;
>> 0001-Add-command-to-start-Emacs-with-specific-packages.patch]...
>>
>>
>>>> [2. text/x-diff;
>>>> 0002-Add-command-to-start-Emacs-with-specific-packages.patch]...
>>>>
>>>> [3. text/x-diff; 
>>>> 0001-Add-a-function-to-query-the-Emacs-executable.patch]...
>>
>> I have slightly modified your version, fixing issues I had, in case
>> anyone else wants to try it out:
>
> Thanks, sorry to not provide the CRM, I quickly wrote this.

np.

>>         (defun package-isolate (packages)
>>           "Start an uncustomised Emacs and only load a set of PACKAGES."
>>           (interactive
>>            (list (mapcar #'intern (completing-read-multiple "Packages: " 
>> (mapcar #'car (package--alist))))))
>>           (let* ((name (concat "package-isolate-" (mapconcat #'symbol-name 
>> packages ",")))
>>                  (deps (mapcan #'package--dependencies packages)))
>>             (apply #'start-process (concat "*" name "*") nil
>>                    (list (file-truename (expand-file-name invocation-name 
>> invocation-directory))
>>                          "--quick" "--debug-init"
>>                          (format "--eval=%S"
>>                                  `(progn
>>                                     (require 'warnings)
>>                                     (add-to-list 'warning-suppress-log-types 
>> 'initialization)
>>                                     (require 'package)
>>                                     (setq package-load-list
>>                                           ',(mapcar (lambda (p) (list p t)) 
>> (append packages deps)))
>>                                     (package-initialize)))))))