emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs Package Management


From: Tom Tromey
Subject: Re: Emacs Package Management
Date: Wed, 16 Sep 2009 19:44:05 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

>>>>> "Stephen" == Stephen Eilert <address@hidden> writes:

Stephen> To sum it up: there *is* interest in a packaging feature, and
Stephen> the issues seem to be mostly in the area of copyright
Stephen> assignment.

I suppose copyright assignment of packages.  There is no issue with
package.el itself, I will donate it any time.

Stephen> ELPA is a nice starting point. But I think it is
Stephen> disproportionally easy to download packages, as opposed to
Stephen> submitting them. For single files, I would very much like to
Stephen> have a M-x submit-package, and have it do anything required to
Stephen> upload it, adding licenses and so on.

Yeah.  I would like this too, but that would mean finding time to write
the web app and everything else :-)

Stephen> Dependencies management is also nice, but we'd have to have a
Stephen> way to identify packages.

Yes, this is something that package.el provides.  One thing that would
be nice is to have Emacs also advertise the packages it provides -- that
is, the ones that are also on separate release schedules.  Right now I
track this information by hand, but that is somewhat error prone.

Stephen> And, most importantly, failing packages should not interrupt
Stephen> emacs startup.  I've implemented a simple system(for my own
Stephen> use) where it creates a buffer with package load
Stephen> status. Failing packages are skipped, but obviously there is no
Stephen> way to undo side-effects.

If this is a problem with package.el or some package in ELPA, please
send me some email (preferably to the ELPA address).  I will try to fix
any problems soon.

In general my rule with ELPA has been to try to avoid this problem by
only uploading packages that will at least properly "activate".  Testing
this could be automated and made more robust, but again, I have little
time.

Tom




reply via email to

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