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

[Philip Kaludercic <philipk@posteo.net>]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I wonder if indicating a "commit mismatch" for remote packages might
>> be interesting (we explicitly don't want this for local packages,
>> e.g. packages installed via package-vc).
>
> Depending on the logic of "commit mismatch" detection, that may be
> sufficient.  Could you describe what you had in mind?

In your case/the case of julia-mode, something like

  Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH).

with a help annotation.

>> Could you perhaps elaborate on why you consider this to be a bug?
>
> To be clear I meant that it's a bug in the remote package.

Perhaps I am being pedantic, but this sounds like a mistake, not a /bug/
in the code itself.

> Specifically, in the case of julia-mode, it was a bug for it to have
> introduced the 0.4 package header in a commit that was different from
> the one that was tagged as 0.4.

Do you know which of the two is correct?  In cases like these, it sounds
like one should contact the maintainers to remind them that they
shouldn't repeat the same issue in the future.

> I don't consider this to be a bug in package.el.  However, if package.el
> had made it obvious that the 0.4 version from melpa-stable isn't the
> same as the 0.4 version from nongnu, it would have saved me some
> headache.
>
> For my part, I know better than to take version numbers at face value
> now, especially when they are from different archives.
>
>>>> IIRC the commit of a VC package should appear under the commit header.
>>>
>>> That necessitates additional clicks.  If those clicks or button pushes
>>> could be avoided it would improve user convenience.
>>
>> True, but there are many things that could be made more convenient that
>> only interest few people.  I am trying to understand why this is
>> something that would interest everyone.
>
> I don't believe this would interest _everyone_.  I also don't believe
> that that's the necessary bar for a feature.  One might argue that this
> is too niche a feature.  I don't believe so, but I also am not sure if
> my opinion on the matter has any significance.

You are right, I misphrased that.  It should be "always".  If two
package versions are based on the same commit, then I'd argue this
information is not interesting, as this is assumed to be the default.

> The people to whom this would be of interest would be users who have
> melpa-stable enabled and who use some packages that are available both
> on melpa-stable and either nongnu or gnu.
>
>> What I had in mind was using `vc-git-symbolic-commit'.  So in the case
>> of Git: If the commit
>> is following the "master" branch, then it would print "master" instead
>> a commit hash, likewise if the package is checked out on some tag, it
>> could display that.
>
> At least for the scenario I am considering, symbolic names would not be
> very useful.  Commits are useful because they are unique (more or less).

-- 
	Philip Kaludercic on siskin