* package-update-all from command line
@ 2022-05-24 3:42 Sam Steingold
2022-05-24 13:54 ` Stefan Monnier
2022-05-25 1:26 ` Lars Ingebrigtsen
0 siblings, 2 replies; 19+ messages in thread
From: Sam Steingold @ 2022-05-24 3:42 UTC (permalink / raw)
To: emacs-devel
I would like to be able to update packages from the command line, and
thanks to Lars, I now can do
--8<---------------cut here---------------start------------->8---
emacs -batch -funcall package-initialize -load ~/.emacs.elc -funcall package-update-all
--8<---------------cut here---------------end--------------->8---
Alas, this has two problems:
1. It prints "No packages to update" even though M-x list-packages RET
reports "Packages that can be upgraded: 3; type ‘U’ to mark for upgrading".
2. Loading ~/.emacs.elc is relatively slow (e.g., because it fetches a
remote `remember-data-file'). so I would rather use something smaller.
After much experimentation, it turned out that this is what I need:
--8<---------------cut here---------------start------------->8---
emacs -batch -load package -load ~/.config/emacs/package-quickstart.elc \
-eval '(setq package-selected-packages (delete-dups package-activated-list))' \
-eval '(push (quote ("melpa" . "https://melpa.org/packages/")) package-archives)' \
-eval '(package-update-all nil)'
--8<---------------cut here---------------end--------------->8---
Note that I had to specify the `QUERY` argument to `package-update-all'
explicitly, otherwise it asked me "3 packages to update. Do it?(yes or no)"
I wonder if this feature is working as intended, or maybe there is a way
to make it nicer.
E.g., I would like to save `package-archives' in
`package-quickstart-file' so that I won't have to specify it on the
command line (it is set in ~/.emacs, of course).
Thanks.
--
Sam Steingold (http://sds.podval.org/) on Pop 22.04 (jammy) X 11.0.12101003
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://thereligionofpeace.com https://fairforall.org https://ij.org/
Don't be afraid of happiness. It does not exist.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 3:42 package-update-all from command line Sam Steingold
@ 2022-05-24 13:54 ` Stefan Monnier
2022-05-24 14:05 ` Eli Zaretskii
2022-05-24 15:04 ` package-update-all from command line Sam Steingold
2022-05-25 1:26 ` Lars Ingebrigtsen
1 sibling, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2022-05-24 13:54 UTC (permalink / raw)
To: emacs-devel
> I would like to be able to update packages from the command line, and
> thanks to Lars, I now can do
> --8<---------------cut here---------------start------------->8---
> emacs -batch -funcall package-initialize -load ~/.emacs.elc -funcall package-update-all
> --8<---------------cut here---------------end--------------->8---
`package-initialize` should basically never be needed any more (other
than internally within `package.el`). `package-activate-all` should
be sufficient.
If not, report it as a bug.
> Alas, this has two problems:
>
> 1. It prints "No packages to update" even though M-x list-packages RET
> reports "Packages that can be upgraded: 3; type ‘U’ to mark for upgrading".
I'll let the author of `package-update-all` deal with this part :-)
> 2. Loading ~/.emacs.elc is relatively slow (e.g., because it fetches a
> remote `remember-data-file'). so I would rather use something smaller.
If it hurts don't do that: e.g., only fetch that remote file
if (not noninteractive) or something like that.
> --8<---------------cut here---------------start------------->8---
> emacs -batch -load package -load ~/.config/emacs/package-quickstart.elc \
The above 2 steps should be subsumed by calling `package-activate-all`
> -eval '(setq package-selected-packages (delete-dups package-activated-list))' \
Hmm... I wonder why you needed that.
> -eval '(push (quote ("melpa" . "https://melpa.org/packages/")) package-archives)' \
This one basically plays the role of a stripped down version of your `.emacs`.
> E.g., I would like to save `package-archives' in
> `package-quickstart-file' so that I won't have to specify it on the
> command line (it is set in ~/.emacs, of course).
I can't think of a way to do that in a way that's reliable for all the
various ways this var can be set. :-(
I have wished for there to be a init file that's loaded in
batch sessions. Sometimes I feel like `early-init.el` could
be this file; i.e. load it when in `--batch` as well.
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 13:54 ` Stefan Monnier
@ 2022-05-24 14:05 ` Eli Zaretskii
2022-05-24 16:00 ` Loading early-init.el in batch mode (was: package-update-all from command line) Stefan Monnier
2022-05-24 15:04 ` package-update-all from command line Sam Steingold
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-05-24 14:05 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 24 May 2022 09:54:30 -0400
>
> I have wished for there to be a init file that's loaded in
> batch sessions. Sometimes I feel like `early-init.el` could
> be this file; i.e. load it when in `--batch` as well.
I don't think that's a good idea, given that we don't limit users in
what should go into that file. If you want a special init file for
batch sessions, we should introduce a special file and document it as
reserved only for settings that are supposed to work in -batch
sessions.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 13:54 ` Stefan Monnier
2022-05-24 14:05 ` Eli Zaretskii
@ 2022-05-24 15:04 ` Sam Steingold
2022-05-24 15:52 ` Stefan Monnier
1 sibling, 1 reply; 19+ messages in thread
From: Sam Steingold @ 2022-05-24 15:04 UTC (permalink / raw)
To: emacs-devel, Stefan Monnier; +Cc: Lars Magne Ingebrigtsen
> * Stefan Monnier <zbaavre@veb.hzbagerny.pn> [2022-05-24 09:54:30 -0400]:
>
>> I would like to be able to update packages from the command line, and
>> thanks to Lars, I now can do
>> --8<---------------cut here---------------start------------->8---
>> emacs -batch -funcall package-initialize -load ~/.emacs.elc -funcall package-update-all
>> --8<---------------cut here---------------end--------------->8---
>
> `package-initialize` should basically never be needed any more (other
> than internally within `package.el`). `package-activate-all` should
> be sufficient.
> If not, report it as a bug.
replacing `package-initialize' with `package-activate-all' above results in
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (void-function package-update-all)
--8<---------------cut here---------------end--------------->8---
>> 1. It prints "No packages to update" even though M-x list-packages RET
>> reports "Packages that can be upgraded: 3; type ‘U’ to mark for upgrading".
>
> I'll let the author of `package-update-all` deal with this part :-)
.emacs fragment for Lars:
--8<---------------cut here---------------start------------->8---
(with-eval-after-load "package"
(dolist (s '(("melpa" . "https://melpa.org/packages/")))
(add-to-list 'package-archives s)))
--8<---------------cut here---------------end--------------->8---
>> 2. Loading ~/.emacs.elc is relatively slow (e.g., because it fetches a
>> remote `remember-data-file'). so I would rather use something smaller.
>
> If it hurts don't do that: e.g., only fetch that remote file
> if (not noninteractive) or something like that.
I restart emacs only once a week, when I rebuild it.
Not a problem interactively.
>> --8<---------------cut here---------------start------------->8---
>> emacs -batch -load package -load ~/.config/emacs/package-quickstart.elc \
>
> The above 2 steps should be subsumed by calling `package-activate-all`
no, as indicated by the error above, `package-activate-all' does not
load package, so `package-update-all' and `package-archives' is still
not available:
--8<---------------cut here---------------start------------->8---
Error: void-variable (package-archives)
--8<---------------cut here---------------end--------------->8---
>> -eval '(setq package-selected-packages (delete-dups package-activated-list))' \
>
> Hmm... I wonder why you needed that.
because otherwise `package-selected-packages' is nil and there is
nothing to update.
and I need `delete-dups' because `package-activated-list' will repeat
all installed packages as many times as `list-packages' or
`package-quickstart-refresh' was called.
>> -eval '(push (quote ("melpa" . "https://melpa.org/packages/")) package-archives)' \
>
> This one basically plays the role of a stripped down version of your `.emacs`.
yep - a fraction of a percent.
>> E.g., I would like to save `package-archives' in
>> `package-quickstart-file' so that I won't have to specify it on the
>> command line (it is set in ~/.emacs, of course).
>
> I can't think of a way to do that in a way that's reliable for all the
> various ways this var can be set. :-(
just add a setq at the end, like we already do with `package-activated-list'.
Thank you for your reply.
--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://jij.org https://camera.org https://mideasttruth.com
There are two ways to win an argument with a woman. Neither works.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 15:04 ` package-update-all from command line Sam Steingold
@ 2022-05-24 15:52 ` Stefan Monnier
2022-05-24 19:01 ` Sam Steingold
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-24 15:52 UTC (permalink / raw)
To: emacs-devel; +Cc: Lars Magne Ingebrigtsen
> replacing `package-initialize' with `package-activate-all' above results in
>
> --8<---------------cut here---------------start------------->8---
> Debugger entered--Lisp error: (void-function package-update-all)
> --8<---------------cut here---------------end--------------->8---
Hmm... maybe it should be autoloaded, then?
>>> -eval '(setq package-selected-packages (delete-dups package-activated-list))' \
>> Hmm... I wonder why you needed that.
> because otherwise `package-selected-packages' is nil and there is
> nothing to update.
I can't see in the code where `package-update-all` ends up using
`package-selected-packages`.
At the place where it uses it, it probably should auto-initialize it if
it's still nil.
> and I need `delete-dups' because `package-activated-list' will repeat
> all installed packages as many times as `list-packages' or
> `package-quickstart-refresh' was called.
I can't see in the code many efforts to make absolutely sure that
duplicates don't make it there, admittedly.
But `package-quickstart-refresh` let-binds it to nil around the whole
call so it shouldn't be able to modify it at all. And I can't think of
any reason why `list-packages` would modify that var either.
IOW, sounds like a bug somewhere.
>>> E.g., I would like to save `package-archives' in
>>> `package-quickstart-file' so that I won't have to specify it on the
>>> command line (it is set in ~/.emacs, of course).
>> I can't think of a way to do that in a way that's reliable for all the
>> various ways this var can be set. :-(
[ Too many "way"s here, sorry. ]
> just add a setq at the end, like we already do with `package-activated-list'.
`package-activated-list` is easy because it's not meant to be set by
the user.
`package-archives` is a completely different problem because it's
a defcustom which may be set to a different value in the user's config
in all kinds of different ways, and which may be eval'd either before or
after loading the quickstart file, so it *would* mess up the user's
config in various circumstances.
We could do it upon the user's request, of course, but doing it
automatically by default is not really an option :-(
Maybe a more general way to attack this problem would be to try and
create a "quickinit.el" file which is a bit like a "dump" of the user's
config, so it can be used instead of loading `init.el`?
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Loading early-init.el in batch mode (was: package-update-all from command line)
2022-05-24 14:05 ` Eli Zaretskii
@ 2022-05-24 16:00 ` Stefan Monnier
2022-05-24 18:58 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-24 16:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
>> I have wished for there to be a init file that's loaded in
>> batch sessions. Sometimes I feel like `early-init.el` could
>> be this file; i.e. load it when in `--batch` as well.
> I don't think that's a good idea,
I'm not completely sold on the idea either. More specifically, I wish
we'd done it back when we introduced that file, but doing it now risks
introducing regressions.
> given that we don't limit users in what should go into that file.
We don't give guidelines, but by virtue of it being loaded before the
GUI is setup, it does have similar technical limitations to the ones
that apply for batch uses.
> If you want a special init file for batch sessions, we should
> introduce a special file and document it as reserved only for settings
> that are supposed to work in -batch sessions.
We could, indeed. I can't think of any reason why we wouldn't want to
load that same file in interactive sessions, tho (IOW, I can't think of
too many user settings which would be useful for batch use and
undesirable for interactive use).
If we add such a file, we should be careful to allow something like
`--batch -q` to prevent loading that file.
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Loading early-init.el in batch mode (was: package-update-all from command line)
2022-05-24 16:00 ` Loading early-init.el in batch mode (was: package-update-all from command line) Stefan Monnier
@ 2022-05-24 18:58 ` Eli Zaretskii
0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-05-24 18:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 24 May 2022 12:00:40 -0400
>
> > given that we don't limit users in what should go into that file.
>
> We don't give guidelines, but by virtue of it being loaded before the
> GUI is setup, it does have similar technical limitations to the ones
> that apply for batch uses.
Not really: quite a lot of GUI-related settings can be done before the
GUI setup is done.
> > If you want a special init file for batch sessions, we should
> > introduce a special file and document it as reserved only for settings
> > that are supposed to work in -batch sessions.
>
> We could, indeed. I can't think of any reason why we wouldn't want to
> load that same file in interactive sessions, tho (IOW, I can't think of
> too many user settings which would be useful for batch use and
> undesirable for interactive use).
That'd be risking problems that can be avoided. If we document that
file as being loaded only by batch sessions, we won't need to solve
bugs where people loaded it in interactive sessions and that didn't do
what they expected.
> If we add such a file, we should be careful to allow something like
> `--batch -q` to prevent loading that file.
Probably.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 15:52 ` Stefan Monnier
@ 2022-05-24 19:01 ` Sam Steingold
2022-05-24 19:55 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Sam Steingold @ 2022-05-24 19:01 UTC (permalink / raw)
To: emacs-devel, Stefan Monnier
> * Stefan Monnier <zbaavre@veb.hzbagerny.pn> [2022-05-24 11:52:32 -0400]:
>
>> replacing `package-initialize' with `package-activate-all' above results in
>>
>> --8<---------------cut here---------------start------------->8---
>> Debugger entered--Lisp error: (void-function package-update-all)
>> --8<---------------cut here---------------end--------------->8---
>
> Hmm... maybe it should be autoloaded, then?
probably...
>>>> -eval '(setq package-selected-packages (delete-dups package-activated-list))' \
>>> Hmm... I wonder why you needed that.
>> because otherwise `package-selected-packages' is nil and there is
>> nothing to update.
>
> I can't see in the code where `package-update-all` ends up using
> `package-selected-packages`.
> At the place where it uses it, it probably should auto-initialize it if
> it's still nil.
note that it should be auto-initialized based on package-quickstart.el
which contains the list of packages that the used installed.
>> and I need `delete-dups' because `package-activated-list' will repeat
>> all installed packages as many times as `list-packages' or
>> `package-quickstart-refresh' was called.
>
> I can't see in the code many efforts to make absolutely sure that
> duplicates don't make it there, admittedly.
> But `package-quickstart-refresh` let-binds it to nil around the whole
> call so it shouldn't be able to modify it at all. And I can't think of
> any reason why `list-packages` would modify that var either.
> IOW, sounds like a bug somewhere.
The breakage may come from loading package-quickstart.el multiple times.
One is not supposed to do that, of course...
>>>> E.g., I would like to save `package-archives' in
>>>> `package-quickstart-file' so that I won't have to specify it on the
>>>> command line (it is set in ~/.emacs, of course).
>>> I can't think of a way to do that in a way that's reliable for all the
>>> various ways this var can be set. :-(
> [ Too many "way"s here, sorry. ]
>> just add a setq at the end, like we already do with `package-activated-list'.
>
> `package-activated-list` is easy because it's not meant to be set by
> the user.
>
> `package-archives` is a completely different problem because it's
> a defcustom which may be set to a different value in the user's config
> in all kinds of different ways, and which may be eval'd either before or
> after loading the quickstart file, so it *would* mess up the user's
> config in various circumstances.
so save a new non-user variable like `package-current-archives' instead,
so that I can set `package-archives' from it on the command line.
> Maybe a more general way to attack this problem would be to try and
> create a "quickinit.el" file which is a bit like a "dump" of the user's
> config, so it can be used instead of loading `init.el`?
here we already have package-quickstart.el which can be re-used.
--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://honestreporting.com https://camera.org https://thereligionofpeace.com
MS: Brain off-line, please wait.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 19:01 ` Sam Steingold
@ 2022-05-24 19:55 ` Stefan Monnier
2022-05-25 15:14 ` Sam Steingold
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-24 19:55 UTC (permalink / raw)
To: emacs-devel
>>>>> -eval '(setq package-selected-packages (delete-dups package-activated-list))' \
>>>> Hmm... I wonder why you needed that.
>>> because otherwise `package-selected-packages' is nil and there is
>>> nothing to update.
>>
>> I can't see in the code where `package-update-all` ends up using
>> `package-selected-packages`.
>> At the place where it uses it, it probably should auto-initialize it if
>> it's still nil.
>
> note that it should be auto-initialized based on package-quickstart.el
> which contains the list of packages that the used installed.
That's unrelated, actually: when nil `package-selected-packages` can be
auto-initialized based on the set of packages currently installed.
`package-quickstart.el` doesn't set `package-selected-packages` nor does
it pay attention to the set of packages currently installed: it just
activates in one go a particular set of packages (which are presumably
all still installed in the same way as when that quickstart file was
created).
In any case, the question is to figure out where `package-update-all`
ends up using `package-selected-packages` and from there to figure out
where to add the same
(unless (consp package-selected-packages)
(package--save-selected-packages (package--find-non-dependencies)))
as currently found in `package--user-selected-p`.
[ Tho maybe, we shouldn't "save" this, really. ]
>>> and I need `delete-dups' because `package-activated-list' will repeat
>>> all installed packages as many times as `list-packages' or
>>> `package-quickstart-refresh' was called.
>>
>> I can't see in the code many efforts to make absolutely sure that
>> duplicates don't make it there, admittedly.
>> But `package-quickstart-refresh` let-binds it to nil around the whole
>> call so it shouldn't be able to modify it at all. And I can't think of
>> any reason why `list-packages` would modify that var either.
>> IOW, sounds like a bug somewhere.
>
> The breakage may come from loading package-quickstart.el multiple times.
Ah, that might be it. Indeed the quickstart file contains:
`(setq package-activated-list
(append ',(mapcar #'package-desc-name package--quickstart-pkgs)
package-activated-list))
:-(
> One is not supposed to do that, of course...
If it happens accidentally, please report it as a bug.
>> `package-archives` is a completely different problem because it's
>> a defcustom which may be set to a different value in the user's config
>> in all kinds of different ways, and which may be eval'd either before or
>> after loading the quickstart file, so it *would* mess up the user's
>> config in various circumstances.
> so save a new non-user variable like `package-current-archives' instead,
> so that I can set `package-archives' from it on the command line.
Setting `package-archives` from `package-current-archives` doesn't seem
much easier than the ad-hoc addition of "melpa" you're currently using,
so it doesn't seem like a great improvement.
I think we'd want to try and find a more general solution to a more
general problem.
>> Maybe a more general way to attack this problem would be to try and
>> create a "quickinit.el" file which is a bit like a "dump" of the user's
>> config, so it can be used instead of loading `init.el`?
> here we already have package-quickstart.el which can be re-used.
AFAIK the problem is not how to name the file but what to put into it.
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 3:42 package-update-all from command line Sam Steingold
2022-05-24 13:54 ` Stefan Monnier
@ 2022-05-25 1:26 ` Lars Ingebrigtsen
2022-05-25 4:58 ` Tassilo Horn
1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-25 1:26 UTC (permalink / raw)
To: emacs-devel
Sam Steingold <sds@gnu.org> writes:
> I would like to be able to update packages from the command line, and
> thanks to Lars, I now can do
>
> emacs -batch -funcall package-initialize -load ~/.emacs.elc -funcall package-update-all
>
> Alas, this has two problems:
>
> 1. It prints "No packages to update" even though M-x list-packages RET
> reports "Packages that can be upgraded: 3; type ‘U’ to mark for upgrading".
I've now tweaked package-update-all prompting, but I'm not able to
reproduce the problem otherwise.
emacs -batch -l ~/.emacs -f package-update-all
updated a bunch of packages for me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-25 1:26 ` Lars Ingebrigtsen
@ 2022-05-25 4:58 ` Tassilo Horn
2022-05-25 12:05 ` Lars Ingebrigtsen
0 siblings, 1 reply; 19+ messages in thread
From: Tassilo Horn @ 2022-05-25 4:58 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
>> I would like to be able to update packages from the command line, and
>> thanks to Lars, I now can do
>>
>> emacs -batch -funcall package-initialize -load ~/.emacs.elc -funcall
>> package-update-all
>>
>> Alas, this has two problems:
>>
>> 1. It prints "No packages to update" even though M-x list-packages
>> RET reports "Packages that can be upgraded: 3; type ‘U’ to mark for
>> upgrading".
>
> I've now tweaked package-update-all prompting, but I'm not able to
> reproduce the problem otherwise.
>
> emacs -batch -l ~/.emacs -f package-update-all
>
> updated a bunch of packages for me.
When seeing that command being introduced, I've also made my own version
(defun th/package-update-all ()
(interactive)
(package-refresh-contents)
(package-update-all (called-interactively-p)))
because package-update-all doesn't seem to update the package database.
I can't see the "Contacting host: elpa.gnu.org" message and the same for
the other archives.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-25 4:58 ` Tassilo Horn
@ 2022-05-25 12:05 ` Lars Ingebrigtsen
2022-05-25 12:27 ` Tassilo Horn
0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-25 12:05 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> When seeing that command being introduced, I've also made my own version
>
> (defun th/package-update-all ()
> (interactive)
> (package-refresh-contents)
> (package-update-all (called-interactively-p)))
>
> because package-update-all doesn't seem to update the package database.
> I can't see the "Contacting host: elpa.gnu.org" message and the same for
> the other archives.
Yes, perhaps -update-all should also call -refresh-contents?
By the way, the following also seems to work:
./src/emacs -batch -l ~/.emacs -f package-refresh-contents -f package-update-all
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-25 12:05 ` Lars Ingebrigtsen
@ 2022-05-25 12:27 ` Tassilo Horn
2022-05-27 10:21 ` Lars Ingebrigtsen
0 siblings, 1 reply; 19+ messages in thread
From: Tassilo Horn @ 2022-05-25 12:27 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
Hi Lars,
>> When seeing that command being introduced, I've also made my own version
>>
>> (defun th/package-update-all ()
>> (interactive)
>> (package-refresh-contents)
>> (package-update-all (called-interactively-p)))
>>
>> because package-update-all doesn't seem to update the package database.
>> I can't see the "Contacting host: elpa.gnu.org" message and the same for
>> the other archives.
>
> Yes, perhaps -update-all should also call -refresh-contents?
IMHO, yes. The same question applies to `package-update' but there it
would be annoying if it always refreshed first when updating one package
after the other. So maybe the refreshes should be restricted to "there
hasn't been a refresh in the last <N> <TIMEUNIT>".
> By the way, the following also seems to work:
>
> ./src/emacs -batch -l ~/.emacs -f package-refresh-contents -f package-update-all
Indeed. So you another way to handle this issue was to just document
the current behavior and add a command line update-all recipe.
However, your "emacs -batch -l ~/.emacs ..." recipe doesn't work with
every init file, at least it didn't work with mine. I use
`user-init-file' in my ~/.emacs.d/init.el which is nil if emacs is
started with -batch, and it seems that packages are not initialized so
emacs complained about void-function use-package. I've catered for it
in my init file now but I guess -batch -l <init-file> cannot be
recommended as a general practice for this purpose.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-24 19:55 ` Stefan Monnier
@ 2022-05-25 15:14 ` Sam Steingold
2022-05-25 16:13 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Sam Steingold @ 2022-05-25 15:14 UTC (permalink / raw)
To: emacs-devel, Stefan Monnier
> * Stefan Monnier <zbaavre@veb.hzbagerny.pn> [2022-05-24 15:55:41 -0400]:
>
> Ah, that might be it. Indeed the quickstart file contains:
>
> `(setq package-activated-list
> (append ',(mapcar #'package-desc-name package--quickstart-pkgs)
> package-activated-list))
>
> :-(
>
>> One is not supposed to do that, of course...
>
> If it happens accidentally, please report it as a bug.
WDYM "accidentally"?
At any rate, I think replacing `append' with `cl-union' (or equivalent)
in the code above would be a good idea.
>>> `package-archives` is a completely different problem because it's
>>> a defcustom which may be set to a different value in the user's config
>>> in all kinds of different ways, and which may be eval'd either before or
>>> after loading the quickstart file, so it *would* mess up the user's
>>> config in various circumstances.
>> so save a new non-user variable like `package-current-archives' instead,
>> so that I can set `package-archives' from it on the command line.
>
> Setting `package-archives` from `package-current-archives` doesn't seem
> much easier than the ad-hoc addition of "melpa" you're currently using,
> so it doesn't seem like a great improvement.
It helps me maintain my additions to `package-archives' in _one_ place
(.emacs) instead of 2 places (.emacs + the command line).
>>> Maybe a more general way to attack this problem would be to try and
>>> create a "quickinit.el" file which is a bit like a "dump" of the user's
>>> config, so it can be used instead of loading `init.el`?
>> here we already have package-quickstart.el which can be re-used.
>
> AFAIK the problem is not how to name the file but what to put into it.
I am not talking about naming, but rather reusing an existing file for a
related purpose.
--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://thereligionofpeace.com https://www.dhimmitude.org
Beliefs divide, doubts unite.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-25 15:14 ` Sam Steingold
@ 2022-05-25 16:13 ` Stefan Monnier
2022-05-26 15:13 ` Sam Steingold
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-05-25 16:13 UTC (permalink / raw)
To: emacs-devel
>> Ah, that might be it. Indeed the quickstart file contains:
>>
>> `(setq package-activated-list
>> (append ',(mapcar #'package-desc-name package--quickstart-pkgs)
>> package-activated-list))
>>
>> :-(
>>
>>> One is not supposed to do that, of course...
>> If it happens accidentally, please report it as a bug.
> WDYM "accidentally"?
Hmm... I now see that calling `package-activate-all` twice is all it
takes (I had the impression that I had put a test in there to do
nothing if the packages were already activated).
> At any rate, I think replacing `append' with `cl-union' (or equivalent)
> in the code above would be a good idea.
Indeed a `delete-dups` would be in order.
>> Setting `package-archives` from `package-current-archives` doesn't seem
>> much easier than the ad-hoc addition of "melpa" you're currently using,
>> so it doesn't seem like a great improvement.
> It helps me maintain my additions to `package-archives' in _one_ place
> (.emacs) instead of 2 places (.emacs + the command line).
There are many other ways you can get that same result, tho (fixing
your .emacs so that you can use `-l .emacs` from that command line is
probably the easiest and the most immediately useful).
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-25 16:13 ` Stefan Monnier
@ 2022-05-26 15:13 ` Sam Steingold
2022-05-26 15:35 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Sam Steingold @ 2022-05-26 15:13 UTC (permalink / raw)
To: emacs-devel, Stefan Monnier
> * Stefan Monnier <zbaavre@veb.hzbagerny.pn> [2022-05-25 12:13:30 -0400]:
>
>> At any rate, I think replacing `append' with `cl-union' (or equivalent)
>> in the code above would be a good idea.
>
> Indeed a `delete-dups` would be in order.
Okay, so may I push
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 3a05005fb5..4d95e9437a 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -4294,8 +4294,9 @@ package-quickstart-refresh
(insert ")\n")))
(pp `(defvar package-activated-list) (current-buffer))
(pp `(setq package-activated-list
- (append ',(mapcar #'package-desc-name package--quickstart-pkgs)
- package-activated-list))
+ (delete-dups
+ (append ',(mapcar #'package-desc-name package--quickstart-pkgs)
+ package-activated-list)))
(current-buffer))
(let ((info-dirs (butlast Info-directory-list)))
(when info-dirs
--8<---------------cut here---------------end--------------->8---
--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2113
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://think-israel.org https://jij.org https://mideasttruth.com
nobody's life, liberty or property are safe while the legislature is in session
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-26 15:13 ` Sam Steingold
@ 2022-05-26 15:35 ` Stefan Monnier
0 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2022-05-26 15:35 UTC (permalink / raw)
To: emacs-devel
> Okay, so may I push
Yes, please ;-)
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-25 12:27 ` Tassilo Horn
@ 2022-05-27 10:21 ` Lars Ingebrigtsen
2022-05-27 20:33 ` Tassilo Horn
0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-27 10:21 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Yes, perhaps -update-all should also call -refresh-contents?
>
> IMHO, yes.
I've now done this.
> The same question applies to `package-update' but there it
> would be annoying if it always refreshed first when updating one package
> after the other. So maybe the refreshes should be restricted to "there
> hasn't been a refresh in the last <N> <TIMEUNIT>".
Yes, perhaps that'd be nice? But I'd expect somebody who'd use that
function would already know that the package in question has an update,
so a refresh might not be vital there.
Or... Hm. No, I think you're right. Perhaps it should only do these
refreshes when called interactively, though?
> However, your "emacs -batch -l ~/.emacs ..." recipe doesn't work with
> every init file, at least it didn't work with mine. I use
> `user-init-file' in my ~/.emacs.d/init.el which is nil if emacs is
> started with -batch, and it seems that packages are not initialized so
> emacs complained about void-function use-package. I've catered for it
> in my init file now but I guess -batch -l <init-file> cannot be
> recommended as a general practice for this purpose.
It's a bit of a chicken/egg problem, perhaps?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: package-update-all from command line
2022-05-27 10:21 ` Lars Ingebrigtsen
@ 2022-05-27 20:33 ` Tassilo Horn
0 siblings, 0 replies; 19+ messages in thread
From: Tassilo Horn @ 2022-05-27 20:33 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
>> The same question applies to `package-update' but there it would be
>> annoying if it always refreshed first when updating one package after
>> the other. So maybe the refreshes should be restricted to "there
>> hasn't been a refresh in the last <N> <TIMEUNIT>".
>
> Yes, perhaps that'd be nice? But I'd expect somebody who'd use that
> function would already know that the package in question has an
> update, so a refresh might not be vital there.
>
> Or... Hm. No, I think you're right. Perhaps it should only do these
> refreshes when called interactively, though?
I'm not sure how people will use that command. FWIW, I just update all
and be done. But others might want to use package-update in order to
know exactly what is going to be updated and then invoke it multiple
times in a row. In such a case, I think it would be a bit annoying if
it always refreshed just because that might take some seconds.
One easy way around that would be to use completing-read-multiple
instead of completing-read in package-update so that you don't need to
call it multiple times in order to update more than one package.
>> However, your "emacs -batch -l ~/.emacs ..." recipe doesn't work with
>> every init file, at least it didn't work with mine. I use
>> `user-init-file' in my ~/.emacs.d/init.el which is nil if emacs is
>> started with -batch, and it seems that packages are not initialized
>> so emacs complained about void-function use-package. I've catered
>> for it in my init file now but I guess -batch -l <init-file> cannot
>> be recommended as a general practice for this purpose.
>
> It's a bit of a chicken/egg problem, perhaps?
I wouldn't say so. It's just that -batch is more suited for stuff like
"byte-compile this lisp file". I wouldn't mind having additional
options -user-batch and -user-script which act the same as the non-user
versions but do the normal startup initialization.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-05-27 20:33 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-05-24 3:42 package-update-all from command line Sam Steingold
2022-05-24 13:54 ` Stefan Monnier
2022-05-24 14:05 ` Eli Zaretskii
2022-05-24 16:00 ` Loading early-init.el in batch mode (was: package-update-all from command line) Stefan Monnier
2022-05-24 18:58 ` Eli Zaretskii
2022-05-24 15:04 ` package-update-all from command line Sam Steingold
2022-05-24 15:52 ` Stefan Monnier
2022-05-24 19:01 ` Sam Steingold
2022-05-24 19:55 ` Stefan Monnier
2022-05-25 15:14 ` Sam Steingold
2022-05-25 16:13 ` Stefan Monnier
2022-05-26 15:13 ` Sam Steingold
2022-05-26 15:35 ` Stefan Monnier
2022-05-25 1:26 ` Lars Ingebrigtsen
2022-05-25 4:58 ` Tassilo Horn
2022-05-25 12:05 ` Lars Ingebrigtsen
2022-05-25 12:27 ` Tassilo Horn
2022-05-27 10:21 ` Lars Ingebrigtsen
2022-05-27 20:33 ` Tassilo Horn
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).