[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unsupported packages area in the Emacs repo

From: Tom Tromey
Subject: Re: unsupported packages area in the Emacs repo
Date: Fri, 01 Jan 2010 12:18:16 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

>>>>> "Ted" == Ted Zlatanov <address@hidden> writes:

Tom> Recently, Phil Hagelberg <address@hidden> has been looking into
Tom> integrating package.el into Emacs.  I don't know how much progress he
Tom> has made.

Ted> Can you and Phil give us your view?  How would you integrate ELPA
Ted> (package.el) with Emacs, specifically using the DVCS features?

I don't think DVCS matters very much.

Basically what is needed is to integrate package.el into Emacs' startup
sequence.  This requires some build-time changes, so that metadata for
packages is extracted from the source tree; and it requires some source
changes, so that such packages are not automatically added to load-path,
but instead are added by package activation.  Only packages that might
be shipped separately will need this treatment.

package.el requires some metadata to operate properly.  Right now this
metadata is generated by some elisp when I upload a package -- see
package-upload-buffer.  This doesn't scale nicely, though, and I think
the future plan should be to generate this metadata in a commit hook on
the server side.  That is, when a package maintainer pushes a new
version, the hook is run and the various server-side files are rebuilt.

Just doing this would be pretty good.  There are a few feature requests
from ELPA users that would be nice to implement, that require similar
treatment, but that could comfortably be done later.

Ted> That's the technical side, but what about the supported/unsupported
Ted> division?  Have you considered making package.el integrated into the
Ted> Emacs core to work like the Cygwin installer, so unsupported or
Ted> experimental packages can be installed and loaded easily?

package.el really has a few different parts.  The stuff for resolving
dependencies and downloading from ELPA is separate from the
install-and-byte-compile bits.  So, you can use package.el to install a
random .el file, assuming it follows the comment guidelines.

One thing I would like for the long term is to see distros use
package.el's mechanism for installing elisp into site-lisp.  That way
users can see the same activation benefits for things not distributed
with Emacs.  This should be pretty easy to implement.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]