Re: Could we organize all Emacs packages with a single repo system?

[W. Greenhouse]

Hi Andrew,

Andrew Pennebaker <apennebaker@42six.com> writes:

> Marmalade and MELPA are really cool. I'd love to see their packages merged
> into a single system (Marmalade or MELPA, doesn't matter), to reduce
> confusion.
>
> There are some cool packages only in Marmalade, and some nifty packages
> only in MELPA, so I have to instruct Emacs to check *both* repos in my
> .emacs :P Yuck.
>
> If the repos hold different versions, you could get nasty dependency
> conflicts.
>
> And we could finally build in support for the repo into Emacs, so users
> don't have to manually insert the default repo into .emacs. I think M-x
> install-package xyz should work out of the box, zero configuration required.
>
> Of course, configuration would still be available, should further repos
> spring up, and users want to prioritize them over the default one.
>
> Personally, I'd prefer MELPA for its distributed, git-based approach. But
> it's more important to me that Emacs get a standard package management
> system akin to RubyGems, that runs out of the box with no configuration
> required, to make things easier.

FWIW, the `package-archives' already does come preconfigured with the
official GNU ELPA repositoriy as a default:

$ emacs -q

M-: package-archives RET => (("gnu" . "http://elpa.gnu.org/packages/";))

I think that's fine.  I would encourage anyone who's willing to go
through the copyright assignment process to become an Emacs contributor
to put their work in the GNU ELPA (the rules for each are the same).
This is difficult, ethically or practically, for some, which is why we
have the alternate repositories.  Marmalade and MELPA represent
different valid ideas about how to package stuff for Emacs; in Marmalade
the developers themselves do the packaging, while in MELPA, packages are
generated programmatically from upstream sources.  MELPA thus generally
represents a more "bleeding edge" idea of releasing packages.

A more important issue revealed by what you're saying is the fact that
package.el at present lacks a system for overriding the default behavior
of installing the highest-numbered version of a package (something like
`apt-pinning' in Debian).  package.el also lacks support for
cryptographically signed packages/repositories at the moment, which is a
big issue.  Both of these issues are being worked on; hopefully people
will also start submitting more of their stuff to GNU ELPA and helping
it grow.

--
Regards,
WGG