Re: MELPA version numbers

[Sebastian Wiesner]

2013/8/2 Stefan Monnier <address@hidden>:
>> It doesn't track archives independently, and though it actually stores
>> the origin of a package, it doesn't make any use of this information
>> at all.
>
> Not true any more.  When you click on a package, it lists the "other
> versions" it knows about, including their respective origin.
>
> Also you can pin a package to a particular archive.

Indeed, I just discovered "package-pinned-packages", which I presume
is what you are referring to.  In theory it's a nice feature, but I
really dislike the current implementation.  I am actually a bit
disappointed about the quick hack that was use to implement this
feature: When reading the package archives, package.el appears to just
ignore(!) all package versions which are pinned to another archive.

It'll not just put them in a different list, or track them somewhere
else, no, it will completely forget that these package versions even
existed! I can't say that I like this, I am actually quite
disappointed about this quick and dirty hack to implement pinning.

Essentially, "package-archive-contents" doesn't reflect the actual
archive contents anymore, but rather package archives minus some
random, possibly broken user configuration. Essentially
package-archive-contents is not at all reliable anymore, which opens
up for a wide range of hard to debug errors.

For instance, assume the user accidentally pins a package Foo to a
non-existing archive, e.g. by a spelling mistake or whatever.
Package.el hence discards all versions of this package when reading
the contents, so that "package-archive-contents" does not even contain
Foo.  Not because it does exist, no, but just because of a user error.

If the user later attempts to install a package Bar which requires
Foo, she'll be confronted with a plain and completely "package Foo is
not available" message.   Even if it wanted to, package.el could not
warn the user, simply because package.el itself doesn't know about Foo
anymore.

Ideally, pinning would be evaluated when installing a package.  In
this case, package.el could easily detect the above misconfiguration
by looking at "package-archive-contents", and warn about package Bar
being available, but pinned to another archive.  It could even warn
about packages being pinned to non-existing archives.

Please revise the implementation of this feature, and do *not* drop
pinned packages from "package-archive-contents".

>> These limitations sort of defeat the purpose of having
>> multiple archives imho.
>
>> Ideally, package.el would track *all* packages of *all* repositories
>> in "package-archive-contents" (not just the latest out of all
>> repositories), so that packages, which are contained in multiple
>> archives, also appear multiple times in M-x list-packages, once for
>> each archive.
>
> The current package.el does store all packages in
> package-archive-contents, IIRC.

Indeed, I also just discovered it. With the exception of the bad
pinning implementation, this is really nice.  We'll hopefully make use
of this in Carton soon, probably to implement our own approach to
pinning (unless pinning is improved, see above).

> And M-x list-packages only has one
> entry per package, but once you select one of those entries, it should
> tell you about all the versions it knows.
>
> If you prefer to list all the versions directly in list-packages, we
> could add an option for that (patches welcome).

I don't care for the UI, I am only concerned about the implementation
and API of package.el.  I manage my packages through Carton (, and
Carton has to

>> This more sophisticated way of tracking archives would not only neatly
>> solve the problem of MELPA version numbers (without even touching them),
>
> No, it doesn't really solve the problem: most people wouldn't know when
> MELPA's version is out of date.  How would you know to switch archive if
> package.el doesn't tell you that there's a newer version in the
> "gnu" archive?

How exactly can that happen given that MELPA *always* builds VCS
snapshots, with are *by definition* the most recent state of a
package?

Or, in other words, if a GNU ELPA package happens to be more recent
than MELPA, that's a failure in MELPA, because it's the explicit aim
of MELPA to always provide the most recent snapshots of any included
package.