all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Reconsider defaults for use-package-vc-prefer-newest
@ 2024-09-14 12:09 Martin Edström
  2024-09-19 11:49 ` Philip Kaludercic
  0 siblings, 1 reply; 70+ messages in thread
From: Martin Edström @ 2024-09-14 12:09 UTC (permalink / raw)
  To: emacs-devel

Previous discussion: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67955

Currently, the setting of `use-package-vc-prefer-newest` defaults to nil.
I want to bring up some problems with that, and suggest fixes.


PROBLEM 1. MISMATCH WITH PACKAGE-VC

Now use-package :vc is not in line with the behavior of the
package-vc-install command, which fetches the newest commit.

All other package managers I know of also fetch the newest commit.
It is the new use-package :vc which is the odd one out in the
ecosystem, and that can cause stability issues, which I go into
more deeply on this Reddit comment:

https://old.reddit.com/r/emacs/comments/1f8ok7c/do_you_set_packageinstallupgradebuiltin_to_t/llimwe0/


PROBLEM 2. "LAST RELEASE" CANNOT BE ASSUMED TO BE THE LAST RELEASE

I see many packages that have not bumped their Package-Version
header for years.  Perhaps they bump by git tags, or just stopped
bumping versions.  I understand them, since it is a lot of manual
labor to bump it, cut a release commit, then bump again to append a
"-pre" or a ".0.50-git", and to remember to do this everywhere the
version string may occur, like in docs.

I'm also guessing there's a segment of developers that have sensed
that this labor does not end up helping users, so they are not
motivated to keep doing it.  Versions only work as intended if
everyone is versioning regularly, and that is possible to enforce
in a curated repo like GNU Elpa or Debian's repackaged Emacs
packages, but as soon as you also install packages outside of that
repo (and well, most packages are outside), there's no longer any
guarantee and in fact the outdated versions in the curated repo are
likely to cause breakage.

I have personally had to give up on things like ELPA, Melpa Stable,
Debian packages etc.  It always caused instability.  By contrast,
installing 200-400 packages off Melpa, in other words the latest
dev snapshots, has caused me no issues in ~7 years.  So there are
two islands of stability:

1. Stay inside a curated repo entirely
2. Leave the curated repo entirely and install only dev snapshots

Now consider what use-package :vc is for.  It is for installing
things OUTSIDE any curated repo.  I leave it to you to pick a
default setting for `use-package-vc-prefer-newest`.


PROBLEM 3. FORCED REPO REWRITES

I have been forced to use git-filter-repo to rewrite my package's
commit history, to erase all instances of the Package-Version
header.

That's because I had been content to leave the header permanently
at "0.6.0.50-git".  If I kept doing that with the new use-package
:vc in existence, it would cause users to download a horribly
outdated version of my package. If I understand correctly.

I foresee one of two things will happen in the future:

1. More and more package authors carry out the same rewrite I did
2. (more likely) Increased instability as package authors do NOT do
   this rewrite, and users end up with ancient versions all over
   the place


SUGGESTED FIXES

A few possibilities:

1. Change `use-package-vc-prefer-newest` to default to t.

2. Change package-vc so when it walks the commit history to find
   the "last release" or any specific version, it should target the
   newest commit that has the given Package-Version, not the oldest
   commit.

   - That would allow devs to continue having a frozen
     Package-Version without breaking users' setups.

   - Of course, this is effectively the same as option 1, but the
     semantic distinction might be usable in the future to
     e.g. ignore version strings that have a "-pre" inside.

3. Roll out a strategy for moving the entire community onto the
   norm of versioning packages prior to distribution, ideally to
   the extent that Melpa is no longer necessary and can go offline
   in favor of Melpa Stable.  (Until then, Melpa Stable is best
   avoided: https://old.reddit.com/r/emacs/comments/etikbz/)

   Obviously difficult, but as I've said, versioning only works if
   everyone does it.  Specifically, it gives us stability if every
   developer is running the "released version" of most packages
   other than their own.  Currently we have an ecosystem where most
   developers are running the dev snapshot of most packages, and
   any half-measures to change this will only destroy the islands
   of stability that we do currently enjoy.  The topic of this
   email is one such half-measure.

4. Have Emacs ship an automation tool like
   https://github.com/magit/sisyphus, recommend it everywhere, then
   have package.el, package-vc and use-package :vc all throw an
   error on finding more than one commit with a given
   Package-Version string and refuse to install due to ambiguity.

5. Deprecate the Package-Version header and instead maybe let
   package.el perform an automatic string substitution from the
   git/hg tag, if it is still desirable to see the version in the
   source file.  The version could also be substituted into Info
   docs and other places the version string should occur.

   - This is effectively a convenient alternative to option 4.




^ permalink raw reply	[flat|nested] 70+ messages in thread
* Re: Reconsider defaults for use-package-vc-prefer-newest
@ 2024-09-15 17:38 Martin Edström
  2024-09-15 18:24 ` Eli Zaretskii
  0 siblings, 1 reply; 70+ messages in thread
From: Martin Edström @ 2024-09-15 17:38 UTC (permalink / raw)
  To: meedstrom; +Cc: emacs-devel

Now that we're on Emacs 30.0.91, I feel the need to call this out as a fairly release-critical bug. Perhaps I should have emailed bug-gnu-emacs, but now that'd split the discussion over two places, so I'll keep it here.

If this is the kind of setting we can flip in a patch release, then there's no rush. Maybe someone can weigh in about that.

Otherwise it would remain as a source of instability for many years, and conscientious devs would have to insert a check for Emacs 30 that reminds the user that the package may be terribly outdated.

At least one other developer agrees the current setting is "fragile" (https://github.com/melpa/melpa/pull/9133#issuecomment-2351653325).


^ permalink raw reply	[flat|nested] 70+ messages in thread
* Re: Reconsider defaults for use-package-vc-prefer-newest
@ 2024-09-15 19:52 Martin Edström
  2024-09-15 20:41 ` chad
  0 siblings, 1 reply; 70+ messages in thread
From: Martin Edström @ 2024-09-15 19:52 UTC (permalink / raw)
  To: Martin Edstrom; +Cc: Eli Zaretskii, emacs-devel

> I should also point out that the module it was inspired by, vc-use-package, actually had the opposite default!

At least, I infer that it had the opposite default, going by its README (https://github.com/slotThe/vc-use-package), since it sounds like one had to explicitly pass :last-release to get it to download an old commit.


^ permalink raw reply	[flat|nested] 70+ messages in thread

end of thread, other threads:[~2024-10-12  5:46 UTC | newest]

Thread overview: 70+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.