From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Hagelberg Newsgroups: gmane.emacs.devel Subject: Re: Emacs Package Management Date: Sat, 12 Sep 2009 15:38:04 -0700 Message-ID: <87d45vzt4j.fsf@hagelb.org> References: <485b0c380808011427n4d3144eey3f8daf3abac83bf4@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1252795106 17368 80.91.229.12 (12 Sep 2009 22:38:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2009 22:38:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 13 00:38:19 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MmbEX-00047r-So for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2009 00:38:18 +0200 Original-Received: from localhost ([127.0.0.1]:60614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmbEX-0006nT-9p for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 18:38:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmbES-0006nO-Ll for emacs-devel@gnu.org; Sat, 12 Sep 2009 18:38:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmbEO-0006lp-9P for emacs-devel@gnu.org; Sat, 12 Sep 2009 18:38:12 -0400 Original-Received: from [199.232.76.173] (port=60984 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmbEO-0006lm-5S for emacs-devel@gnu.org; Sat, 12 Sep 2009 18:38:08 -0400 Original-Received: from caiajhbdcaib.dreamhost.com ([208.97.132.81]:59173 helo=homiemail-a17.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmbEN-0005Yu-RC for emacs-devel@gnu.org; Sat, 12 Sep 2009 18:38:08 -0400 Original-Received: from enigma (96-26-232-193.sea.clearwire-dns.net [96.26.232.193]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 1EDCB7A805C; Sat, 12 Sep 2009 15:38:06 -0700 (PDT) In-Reply-To: (Tom Tromey's message of "Fri, 01 Aug 2008 16:58:59 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115254 Archived-At: Tom Tromey 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