From: Phil Hagelberg <phil@hagelb.org>
To: Tom Tromey <tromey@redhat.com>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs Package Management
Date: Sat, 12 Sep 2009 15:38:04 -0700 [thread overview]
Message-ID: <87d45vzt4j.fsf@hagelb.org> (raw)
In-Reply-To: <m3ej58xryk.fsf@fleche.redhat.com> (Tom Tromey's message of "Fri, 01 Aug 2008 16:58:59 -0600")
Tom Tromey <tromey@redhat.com> writes:
> Just FYI -- package.el (the elisp side of ELPA) does handle
> dependencies.
>
> There was a discussion a while ago on this list. RMS wanted to
> restrict the available packages to those which had been assigned to
> the FSF, but I did not agree with that.
>
> I would reconsider my position if the Emacs maintainers were
> interested -- I think it would be useful to Emacs users if there were
> a simple, standard way to install and activate packages.
It seems like the dust has settled a bit since the 23 release and we're
out of feature freeze; I wonder if this would be a good time to discuss
the inclusion of package.el again. I've been using it extensively as
well as distributing all of my own elisp through it, and it has greatly
simplified things for me and the users of my software.
Some people have asked what the use would be; why not just include them
in Emacs itself? There are several reasons:
* Much of my elisp is still undergoing a rapid rate of change. Often
versions from two months ago are quite out of date. Using package.el
lets me use my own release cycle rather than relying on Emacs', which
is much improved, but still not appropriate for many projects.
* Emacs is already too big. If we made it easy to install third-party
packages, we could spin many packages already included in Emacs
(perhaps gnus, erc, and org) out into their own independent
projects. We would avoid problems like "the big gnus merge" that
happens every so often as well as allowing them to follow their own
release cycles. In addition, a lot of packages are simply fringe;
they're only useful to a small subset of Emacs users.
* I make use of the cl library, disqualifying much of my code for
inclusion in Emacs proper. I'd venture to say close to a majority of
the nontrivial packages out there do as well.
It sounds like the main objection to its inclusion is that it would
lessen the incentive to assign copyright to the FSF. I don't think this
is necessarily the case; we can hook it up to a repository that only
accepts FSF-copyrighted code. I would be happy to contribute copyright
assignment for the libraries I maintain if it meant that they could be
offered via a package manager built-in to Emacs. I suspect many others
would too.
There would be some work involved in making package.el acceptable for
Emacs. Currently uploading of new packages is done by hand; this process
will need to be automated. Perhaps it could be integrated with Savannah
project hosting; I'm sure something could be worked out.
But I think this is a big opportunity to make it easier for developers
and users of Emacs to share code.
-Phil
next prev parent reply other threads:[~2009-09-12 22:38 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-01 21:27 Emacs Package Management Stephen Eilert
2008-08-01 22:58 ` Tom Tromey
2008-08-01 23:14 ` Phil Hagelberg
2008-08-01 23:25 ` Lennart Borgman (gmail)
2008-08-02 0:13 ` Tom Tromey
2008-08-03 1:33 ` Richard M. Stallman
2008-08-03 18:03 ` Stefan Monnier
2008-08-04 15:33 ` Richard M. Stallman
2008-08-04 19:07 ` Stefan Monnier
2008-08-05 8:04 ` Richard M. Stallman
2008-08-05 13:09 ` Stephen Eilert
2008-08-05 14:39 ` Paul R
2008-08-06 3:35 ` Richard M. Stallman
2009-09-16 22:36 ` Stephen Eilert
2009-09-17 1:44 ` Tom Tromey
2009-09-17 13:43 ` Stefan Monnier
2009-09-17 14:26 ` Tom Tromey
2009-09-17 14:58 ` Eric M. Ludlam
2009-09-28 21:13 ` Phil Hagelberg
2009-09-28 21:48 ` Lennart Borgman
2009-09-28 21:54 ` Chong Yidong
2009-09-28 22:30 ` Phil Hagelberg
2009-09-29 11:31 ` Richard Stallman
2009-09-29 19:18 ` Stefan Monnier
2009-09-29 19:41 ` Tom Tromey
2009-09-30 1:20 ` Stefan Monnier
2009-09-30 2:07 ` Tom Tromey
2009-09-30 4:39 ` Stefan Monnier
2009-09-30 20:18 ` Tom Tromey
2009-10-01 5:01 ` Stefan Monnier
2008-08-02 1:58 ` Stephen Eilert
2008-08-02 3:36 ` Tom Tromey
2008-08-02 17:30 ` Richard M Stallman
2008-08-12 4:10 ` Thomas Lord
2009-09-12 22:38 ` Phil Hagelberg [this message]
2009-09-12 23:30 ` Eric M. Ludlam
2009-09-13 16:40 ` Richard Stallman
2009-09-14 9:07 ` joakim
2009-09-14 9:26 ` David Kastrup
2009-09-15 7:16 ` Richard Stallman
2009-09-15 8:30 ` Miles Bader
2009-09-15 18:15 ` Richard Stallman
2009-09-15 18:58 ` Tom Tromey
2009-09-15 22:08 ` Miles Bader
2009-09-16 15:16 ` Richard Stallman
2009-09-16 18:41 ` Stefan Monnier
2009-09-17 1:05 ` Geoff Gole
2009-09-17 19:50 ` Richard Stallman
2009-09-15 18:55 ` Tom Tromey
2009-09-17 6:37 ` Richard Stallman
2009-09-17 8:28 ` Tassilo Horn
2009-09-17 8:37 ` joakim
2009-09-17 8:48 ` Lennart Borgman
2009-09-17 9:31 ` Tassilo Horn
2009-09-17 10:43 ` Lennart Borgman
2009-09-17 11:50 ` Rupert Swarbrick
2009-09-19 2:40 ` Bob Rogers
2009-09-19 12:10 ` Rupert Swarbrick
2009-09-17 14:24 ` Tom Tromey
2009-09-17 19:22 ` Tassilo Horn
2009-09-17 15:04 ` Eric M. Ludlam
2009-09-17 13:46 ` Stefan Monnier
2009-09-17 14:21 ` Tom Tromey
2009-09-13 17:00 ` Eric Schulte
2008-08-02 14:46 ` Paul R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d45vzt4j.fsf@hagelb.org \
--to=phil@hagelb.org \
--cc=emacs-devel@gnu.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.