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

[Thierry Volpiatto <thievol@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 8327 bytes --]


Philip Kaludercic <philipk@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:
>>>>
>>>>> 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,

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.

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

Ok, I understand.

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

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

Hmm, maybe, I don't have an example in mind though.

> 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 ;-)

> Perhaps it would be better to set `package-directory-list' instead?

Don't know yet.

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

>>> 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)))))))


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]