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:
>
>> The idea is to add a "COMMIT MISMATCH" warning whenever we detect that
>> two packages have different commits.
>
> Which are the two packages being considered?

IIRC the local package you have installed, the package on NonGNU ELPA,
the package on MELPA Stable and the package on MELPA Unstable.

> From my perspective, the following is the desired behaviour: whenever
> package.el has evidence that the same purported package version is being
> served via different commits in the various remote archives (that the
> user has enabled) the user is made aware.  If the package versions
> aren't the same, then no "COMMIT MISMATCH" should be shown.

Yeah, that was my intention as well.

> I.e., the situation of interest is when versions match, but commits
> don't.  If it helps, "NON-UNIQUE COMMIT" might be more accurate, but I
> don't have a strong opinion on the wording.

NON-UNIQUE COMMIT seems more vague to me? 

>> What this doesn't do yet is eliminate false positives, such as
>> different commits between a local version of a package and a remote
>> version.  I guess we are only interested in differences between remote
>> packages, right?
>
> If the package is a local :vc checkout, I don't have strong opinions on
> whether it is considered or ignored.  If the package is an installed
> version (via package-install), then it should be compared against any
> other version that has the same version number (i.e., in the same manner
> as a remote package would be compared).

We don't track multiple version numbers by default, but only the package
as announced by a package archive.  And VC packages seem like a bit of
an headache in this case, as 

>> Does MELPA annotate their packages with commits?
>
> Both MELPA and MELPA Stable seem to.  I am basing this on the assumption
> that the result of button-describe comes from the archive in question.
> If there is a better way to confirm, please do let me know.

I could have checked that as well myself, basically I just had to load

  https://melpa.org/packages/archive-contents

and then one sees that each package description has a :commit entry.

>> +                                   (if (and (not (package-desc-dir opkg))
>> +                                            (equal ocommit commit))
>> +                                       "" ", COMMIT MISMATCH!")))))
>
> If (package-desc-dir opkg) evaluates to non-nil, then the above
> evaluates to ", COMMIT MISMATCH!" which seems incorrect.

Right, I'll try to test this myself before sending you more patches ^^

>> It is documented on the elpa-admin branch:
>>
>> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README?h=elpa-admin&id=9bd65395f1d4875915731ddbdd73a471f10d7794#n215
>
> Thanks for sharing the reference, but why is this not in the default
> branch (which is the only one linked from <https://elpa.gnu.org/>) to
> begin with?  Alternatively, if the elpa-admin variant is considered the
> canonical version, why doesn't the link from <https://elpa.gnu.org/>
> point to
> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README?h=elpa-admin>
> instead?

No reason really, I'll try to update it soon.

> The comment at the top of the file states that the two versions "differ
> slightly".  However, differences in the documentation of supported
> options (regardless of whether or not their use is encouraged) is not
> what I would consider a "slight" difference.
>
>> That being said, I still think that this is a feature that we would want
>> to advise package maintainers not to use.
>
> Agreed.

-- 
	Philip Kaludercic on siskin