unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: "Martin Edström" <meedstrom@runbox.eu>
Cc: "Tony Zorman" <tonyzorman@mailbox.org>,
	 "emacs-devel" <emacs-devel@gnu.org>
Subject: Re: Reconsider defaults for use-package-vc-prefer-newest
Date: Fri, 20 Sep 2024 21:05:57 +0000	[thread overview]
Message-ID: <875xqqm3wq.fsf@posteo.net> (raw)
In-Reply-To: <E1srjRy-0000xc-GK@rmmprod06.runbox> ("Martin Edström"'s message of "Fri, 20 Sep 2024 21:37:54 +0200 (CEST)")

"Martin Edström" <meedstrom@runbox.eu> writes:

> On Fri, 20 Sep 2024 06:57:40 +0200, Tony Zorman <tonyzorman@mailbox.org> wrote:
>> > The thing is that with use-package, having a more deterministic
>> > installation is of interest, especially since use-package is used to
>> > automatically set up an Emacs environment.
>> 
>> I feel like the only way to actually guarantee a deterministic
>> installation procedure is to use outside means (that is, to ping
>> packages to specific versions/commits, either manually or with nix
>> et.al). This can certainly be done with package-vc.el as well, but
>> that's not what happens when one just uses :last-release.
>> 
>>   Tony
>
> Yea, I've recently thought that when you have an ecosystem that grew
> ad-hoc and has not very rigid curating, the solution isn't necessarily
> to start trying to pressure everyone into a reliable release cadence
> and break innocents' initfiles on the way. This isn't corporate, we're
> all lisping for free, and have to lisp smart, not hard. A Pareto
> solution would seem to be lockfiles. That is, an autogenerated file
> specifying pinned versions or commits.

As mentioned before, both ELPA repositories requires releases to be
tagged, and it is not a problem.

> Say there's a file "~/.emacs.d/versions.toml" containing lines such as
>
> vertico = "1.9.0.33"
> consult = "1.8.0.2"
> ess = "24.0.20"
> elpaca = "0.0.2.0.34"
>
> and every time you upgrade, you can have the option of trying to
> upgrade everything at once, rolling back after you find it breaks,
> only upgrade some of them etc.  (Rolling back is a pretty important
> part)

Modulo the part of having separate files in a non-sexp format, this is a
good idea, that I don't think anyone would object to in principle.

> This would be deterministic and everything.  Actually it sort of
> already happens with use-package, nevermind whether it fetches the
> latest snapshot or a "release version", because it's not as if it will
> auto-update every time you start Emacs, only when you manually tell it
> to update. The missing piece is for the user to know how to check
> their `elpa/` subdirectory into a git repo that they can rollback, but
> that's asking a lot for most users.
>
> You might have noticed in the mockup above that I appended a ".0.X"
> number to all the versions.  That's because commit pinning is ugly and
> unsemantic. Here X is just the number of commits since the last
> "release version", no matter how long ago that was.  So Vertico
> 1.9.0.33 is the snapshot that's 33 commits after Vertico 1.9. It's
> totally possible to do something like that (got the idea from
> https://github.com/melpa/package-build/pull/81).
>
> If a developer has no Package-Version and no git tag, it could just be forever at 0.0.X.
>

-- 
	Philip Kaludercic on siskin



  reply	other threads:[~2024-09-20 21:05 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-14 12:09 Reconsider defaults for use-package-vc-prefer-newest Martin Edström
2024-09-19 11:49 ` Philip Kaludercic
2024-09-19 18:50   ` Suhail Singh
2024-09-19 20:11     ` Philip Kaludercic
2024-09-19 20:31       ` Philip Kaludercic
2024-09-20  6:15         ` Eli Zaretskii
2024-09-20 15:14           ` Philip Kaludercic
2024-09-20 15:45             ` Eli Zaretskii
2024-09-20 16:56               ` Philip Kaludercic
2024-09-20 17:37                 ` Eli Zaretskii
2024-09-20 20:43               ` Philip Kaludercic
2024-09-21  7:14                 ` Eli Zaretskii
2024-09-21 14:31                   ` Philip Kaludercic
2024-09-21 15:18                     ` Eli Zaretskii
2024-09-21 15:43                       ` Philip Kaludercic
2024-09-19 21:02       ` Suhail Singh
2024-09-20 20:34         ` Philip Kaludercic
2024-09-20 23:38           ` Suhail Singh
2024-09-21  7:06             ` chad
2024-09-21 14:27               ` Suhail Singh
2024-09-21 15:59             ` Philip Kaludercic
2024-09-21 19:04               ` Suhail Singh
2024-09-22 15:30                 ` Philip Kaludercic
2024-09-22 20:08                   ` Suhail Singh
2024-09-25 12:06                     ` Suhail Singh
2024-09-25 13:15                       ` Philip Kaludercic
2024-09-25 12:07                     ` Philip Kaludercic
2024-09-25 15:15                       ` Suhail Singh
2024-09-25 20:11                         ` Philip Kaludercic
2024-09-25 20:48                           ` Suhail Singh
2024-09-29  2:13                           ` Richard Stallman
2024-09-29  7:25                             ` Philip Kaludercic
2024-09-29 13:55                               ` Suhail Singh
2024-09-26 23:23                     ` Charles Choi
2024-09-27  0:17                       ` Adam Porter
2024-09-27  0:33                       ` Suhail Singh
2024-09-27  6:46                       ` Eli Zaretskii
2024-09-29 14:22                         ` Stefan Kangas
2024-09-29 14:35                           ` Eli Zaretskii
2024-10-11 18:54                         ` Suhail Singh
2024-10-12  5:46                           ` Eli Zaretskii
2024-09-20  4:57   ` Tony Zorman
2024-09-20 19:37     ` Martin Edström
2024-09-20 21:05       ` Philip Kaludercic [this message]
2024-09-21 14:44     ` Philip Kaludercic
2024-09-21 14:58       ` Tony Zorman
2024-09-21 15:10       ` Suhail Singh
2024-09-21 16:09         ` Philip Kaludercic
  -- strict thread matches above, loose matches on Subject: below --
2024-09-15 17:38 Martin Edström
2024-09-15 18:24 ` Eli Zaretskii
2024-09-15 19:46   ` Martin Edstrom
2024-09-16 11:34     ` Eli Zaretskii
2024-09-16 15:24       ` Martin Edström
2024-09-16 16:15       ` Martin Edström
2024-09-16 17:57         ` Eli Zaretskii
2024-09-18 14:30           ` Martin Edström
2024-09-15 19:52 Martin Edström
2024-09-15 20:41 ` chad
2024-09-15 21:09   ` Martin Edstrom
2024-09-15 22:12     ` chad
2024-09-15 23:51       ` Martin Edstrom
2024-09-16 11:50     ` Eli Zaretskii
2024-09-16 16:46       ` Martin Edström
2024-09-16 18:10         ` Eli Zaretskii
2024-09-16 20:16       ` Suhail Singh
2024-09-17 11:44         ` Eli Zaretskii
2024-09-19  3:38           ` Suhail Singh
2024-09-19  6:28             ` Eli Zaretskii
2024-09-19 12:08               ` Suhail Singh
2024-09-19 12:39                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xqqm3wq.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=emacs-devel@gnu.org \
    --cc=meedstrom@runbox.eu \
    --cc=tonyzorman@mailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).