[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changes to make in elpa-packages file for nongnu elpa
From: |
Thierry Volpiatto |
Subject: |
Re: Changes to make in elpa-packages file for nongnu elpa |
Date: |
Wed, 16 Aug 2023 11:55:13 +0000 |
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
signature.asc
Description: PGP signature
- Proposal for 'package-isolate' command, (continued)
- Re: Changes to make in elpa-packages file for nongnu elpa, Eli Zaretskii, 2023/08/15
- Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/15
- Re: Proposal for 'package-isolate' command, Eli Zaretskii, 2023/08/16
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/16
- Re: Changes to make in elpa-packages file for nongnu elpa, Thierry Volpiatto, 2023/08/16
- Re: Changes to make in elpa-packages file for nongnu elpa, Philip Kaludercic, 2023/08/16
- Re: Changes to make in elpa-packages file for nongnu elpa, Thierry Volpiatto, 2023/08/16
- Re: Changes to make in elpa-packages file for nongnu elpa, Philip Kaludercic, 2023/08/16
- Re: Changes to make in elpa-packages file for nongnu elpa,
Thierry Volpiatto <=
- Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/16
- Re: Proposal for 'package-isolate' command, Stefan Kangas, 2023/08/16
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/16
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/17
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/17
- Re: Proposal for 'package-isolate' command, Eshel Yaron, 2023/08/17
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/17
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/17
- Re: Proposal for 'package-isolate' command, Philip Kaludercic, 2023/08/17
- Re: Proposal for 'package-isolate' command, Thierry Volpiatto, 2023/08/17