Re: Reconsider defaults for use-package-vc-prefer-newest

["Martin Edström" <meedstrom@runbox.eu>]

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.

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)

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.