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

[Martin Edström]

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.