Request to add Package to GNU ELPA

[Jonas Bernoulli]

Hello,

I would like to request that "package.el" be added to GNU Elpa as a
"core" package.  This would make new features available to users who are
stuck on older Emacs releases and it would even bring us one step closer
to being able to make backward incompatible changes in the future.

Some examples for why that would be desirable:

- A recent addition that could be useful is the new "package-vc.el"
  (which I think should be distributed as part of the `package' package,
  but it could also be distributed as a separate core package).

  That isn't just useful for users who like to live on the edge.  For
  example, if a package drops support for an old Emacs release, then
  a user who is stuck on that release, may wish to keep using the last
  release of the package that still supports that Emacs release, and
  package-vc would allow them to do just that.

- I don't use Package myself, so I am not fully aware of all the quality
  of live enhancements that surely have accumulated over the years.  But
  I am aware of some small missing features, that would be beneficial to
  users of older Emacs releases.

- For example, I think it would be nice if the columns displayed by
  `list-packages' were customizable.  A user might want to increase the
  width of the "Version" column, so that not every GNU-devel ELPA version
  is truncated, or they might want to add an "Author" column.  We could
  even allow third-party packages to add columns such as "Downloads" or
  "Stars".

- I should also mention that my main motivation for pushing for this
  now, is that I would like to improve version handling.  That is a
  whole other can of worms, so I do not wish to discuss it just yet,
  to avoid distracting from the topic at hand, but I thought I should
  at least mention it.  You might very well end up being against my
  suggestions regarding versions strings, once I present them, but that
  should not be cause to oppose the change requested here as well.  Even
  if my suggestions regarding version strings are ultimately rejected, I
  still think it would be a good idea to add `package' to GNU ELPA, for
  the other reasons presented here.

- I should also make an example for a backward incompatible change.
  Yesterday, in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62524 I
  suggested a backward *compatible* change, but doing it in a backward
  compatible fashion is a bit ugly, and I would like to *eventually*
  replace it with a backward *incompatible* change.

  In short, some packages have multiple maintainers and
  `describe-package' should list them all.  Unfortunately `:maintainer'
  (unlike `:authors') in "archive-contents" can only be a single
  maintainer.  If we listed multiple maintainers, then current versions
  of Package would signal an error.  To address that I proposed that we
  *add* a `:maintainers' property.  Older Package don't know about that
  property and would simply ignore it, and newer Package versions could
  start doing all the maintainers justice.

  It isn't exactly horrible to have both `:maintainer' and
  `:maintainers' for a while, but it is a wart that should be remove
  eventually.  We should avoid accumulating more and more such warts
  over time.  One way of doing that is to simply avoid adding features
  that have to be implemented in an ugly fashion to avoid breaking
  backward compatibility.  I feel that approach has been taken too many
  times in the past.  I myself have certainly done it on several
  occasions.

I mentioned that distributing Package on GNU ELPA would bring us one
step closer to being able to make backward incompatible changes, but
unfortunately it is not enough.  Just because `package' is available
on GNU ELPA, that doesn't mean that it gets installed automatically.

There are two additional steps required.  (1) We have to somehow get
users to install `package' from GNU ELPA a first time, and (2) once
users have done that and a new `package' version becomes available,
they have to be informed about the update and be prompted to install
it.

To address (2), `package-refresh-contents' could be taught to check if
a new `package' version is available, and if that is the case, then it
should prompt the user to update that immediately, before any other
packages.

Addressing (1) is harder, and I don't think it possible to do so in a
way that guarantees that not a single user would end up seeing an error
due to an incompatible change.  On the other hand "archive-contents"
comes with a version field, and if we bump that, we at least get a
meaningful warning: "Package archive version 2 is higher than 1".  This
doesn't say that the solution is to install `package' from GNU ELPA, but
it should be enough to feed into a search engine to get to that answer.

Additionally, we could get many users to install `package' from GNU
ELPA, by making a few popular packages explicitly depend on a `package'
version that is available from GNU ELPA for a few months.

     Thanks for considering this proposal,
     Jonas