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

[Martin Edström]

On Mon, 16 Sep 2024 14:50:51 +0300, Eli Zaretskii <eliz@gnu.org> wrote:
 
> If the problem is that there's a tag with the correct version, but the
> Package-Version heading was not updated, we could perhaps have
> use-package :vc detect that and either display a warning or even
> automatically use the commit with the tag.  Crucially, this is NOT the
> latest commit in the Git repository, it is the commit which has the
> latest release tag -- a far cry from what you suggested originally
> (apologies if I misunderstood you back then.)

I agree it's a good way forward if you are open to look up both the 
Package-Version and the git tag and basically choose the highest-looking 
version between the two.  I had somehow ruled out that option.

What I suggested was, technically, to get the latest commit *with a given 
Package-Version*.

Which need not be the same thing as the latest commit. 

The latest commit could have a pre-release version like "0.6-pre", and so (I 
assume...? Not sure) Emacs would walk back until finding the commit with "0.6" 
and check out that one.

It still looks necessary to me to do the change I suggested, since there exists 
a population of developers who either believe that's how versions work, or who 
do not really bump versions anyway. Since you can't educate everyone, this is a 
situation for picking defaults that handle this reality.

At worst, a package can have just ";; Package-Version: 0" since the very first 
commit, and no tag. I do not think that in this situation, the correct move for 
use-package :vc is to install literally the first commit, when it would be the 
very first package manager to behave in such a way.  

It would be a deliberate introduction of breakage in the ecosystem, mainly 
harming users. It does not matter if the packagers are not doing The Right 
Thing, you gotta protect the users.

Please consider what use-package :vc is for in the first place. It wouldn't be 
used for things that exist on [Non]GNU ELPA, but for what exists off it, so its 
behavior should not be modeled on what you can expect from packages hosted 
there. On the contrary, its behavior can't expect any norms to be followed. 
It's not necessarily incompetence nor disagreement about procedure; many novice 
developers also take their first baby steps in this wilderness.

Of course it is possible to use use-package :vc to install what's on the ELPA, 
but the crowd that cares about running stable releases are going to be the last 
ones to choose to do that.

I can see an user switching to use-package :vc globally, but it'd be precisely 
because they want the bleeding edge version of everything, including the stuff 
on [Non]GNU ELPA.  If they don't want it, they can simply elect not do so for 
the stuff on [Non]GNU ELPA.

> > - User installs Package using (use-package :vc)
> > - User gets the version from 2021
> > - It doesn't seem to work
> > - 10 such users give up on Package
> > - The 11th user files the bug reports
> > - Bug reports are strange and make no sense
> > - User and Developer finally figure out that it's because the user used 
> > (use-package :vc) which fetched the 2021 version
> 
> In any case, I wonder why the above mess you describe is not the fault
> of the package developer, but of Emacs?  It makes little sense to be,
> TBH.

I don't believe in blaming, but Emacs definitely has some of the responsibility 
for the simple reason that this didn't use to happen and people do not expect 
it to happen.

A house of cards falls when someone shakes the table, but it isn't the fault of 
the one who put it together, it is who shook the table when they could instead 
have permitted that artwork to stand.

After knowing how this new Emacs builtin behaves, you can consider it to be the 
fault of the developer who did not take it into account, at least if it is 
reasonable to expect all developers to be professionals that know how every 
package manager works instead of only most of them, having missed this one, but 
even then a crowd will resent this addition to their workload, as I have 
explained prior. 

My own packaging experience would be unharmed if git tags become a valid 
version identifier, but that just affects my packages.  I'd like the ecosystem 
to have guarantees in place, and blaming devs because the fault is theirs will 
not make them do The Right Thing.  The right thing is that Emacs just decline 
to shake the table.

> 
> > To counteract this would amount to a heuristic that looks up the package 
> > repository online and compares the age of recent commits with the commit 
> > fetched by (use-package :vc), but what is the threshold that you would set 
> > to trigger the warning? I don't think it is realistically doable.
> 
> Why not?  Detecting such suspicious "last versions" could be a good
> idea and a good service to users, and is not that hard to implement.

But how would you do it? All it takes is a single commit to introduce changes 
on which another package will rely.  It can be as little as one minute between 
the commits in question.  Or conversely, a package may be mostly unchanged for 
years but that does not mean there is a problem. So that brings us to a bunch 
of UX issues to answer.  Should users "dismiss" each warning individually?  
(Bear in mind there could be hundreds.)  Should these dismissals be recorded in 
`custom-file` or some such location?  It seems like a lot of effort to do well 
compared to my other suggestions, but that's just my impression.