bug#19296: [PATCH] Package archives now have priorities.

[Jorgen Schaefer]

On Sun, 07 Dec 2014 12:56:53 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > When installing packages by name, only packages from archives with
> > the highest priority are considered, before versions are compared.
> 
> What can this be used for (other than the MELPA case, obviously)?

Local/site-wide package archives that provide specific versions for
packages that are required by the site that should not be overridden by
external sources. (Can be emulated by pinning them.)

Adding archives that provide testing or debugging packages which should
not be installed by default, but can be installed by the user if they
want to. (Can be emulated by adding the archive only for the duration
of installing those packages.)

More generally, the use cases are either very similar to the existing
"pinning" functionality, or to adding archives only temporarily, except
the interface is easier to the user and does not require constant
manual work.

> > This solves the "MELPA problem", where MELPA assigns date-based
> > version numbers to packages which override all other archives.
> > Giving MELPA a lower priority means packages are installed from
> > MELPA only when the package is not available from other archives.
> 
> I think the better way to solve the problem of versioning the
> "bleeding edge package" would be to take the base version and tuck
> the date to it (instead of only using the date).
> I.e. file names like foo-mode-1.3.0.20141023.tar.gz where "1.3" is the
> version of the last release.
> 
> Of course that requires a change on MELPA side and I have no idea how
> easy/feasible that would be.  And I'm not completely sure it would
> really be the best option either.

This is not easy for the general MELPA, as not all packages have
version numbers at all, but certainly feasible for MELPA stable.

My patch that would have added this was rejected:

https://github.com/milkypostman/melpa/pull/1771

The version number issues has been raised a few times, and it does not
seem likely to get fixed any time soon.

> > This can be overridden manually by the user.
> 
> An important issue is what happens after the user did such an
> override. In my above suggestion, the behavior would kind of suck
> since package-list would then constantly recommend "upgrading" to the
> official release (since 1.3 is "more uptodate" than "0.0.YYYYMMDD").

Good point. The correct implementation here would likely move the
sorting by version number out of the `package--add-to-archive-contents'
function and into the various users of `package-archive-contents',
which should sort the list depending on their use case. This is a
breaking API change and likely a good deal more work.

Would a patch that does that be more acceptable?

Regards,
Jorgen