Re: MELPA version numbers

[Stefan Monnier]

> 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.

> 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.  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).  The 24.3 code did
sometimes list a package twice (e.g. cl-lib which is both listed as
built-in and as available from GNU ELPA), but when the two versions
don't have the same status ("built-in" vs "available"), they get sorted
by default to completely different places.  For that reason I decided to
have this two-level approach where list-package only lists a package
once and only when you select a package do you see the
available alternatives.

> The user could then choose from which archive a package should be
> installed.

That can be done now.

> And package.el would remember this choice, and look for
> updates only in the archive the package was installed from.

That indeed is not available currently.  I'm not convinced we'd want to
always restrict updates to come from the same archive.  But it could be
a useful option.  Actually, we can already do that via pinning, but it's
obviously not as streamlined as you'd want.
I guess the best way to do it would be something like:
- when the user requests to install a package, check if it's the most recent.
- if not, ask the user if he wants to "pin" that package either to the
  corresponding archive or to the specific version.
Patches welcome.

> 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?

> but also a number of other issues with package.el, such as the
> popular demand to be able to explicitly choose for each package
> whether to use a stable release from GNU ELPA or Marmalade, or a VCS
> snapshot from MELPA.

Hmm... I hadn't heard those requests, but I think I did satisfy them to
some extent in my recentish changes ;-)


        Stefan