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: Integrating package.el (was Re: unsupported packages area in the Emacs repo) Date: Sat, 02 Jan 2010 21:38:58 -0800 Message-ID: <87d41rn3wt.fsf_-_@hagelb.org> References: <878wclke6j.fsf@lifelogs.com> <87k4w5lbyb.fsf_-_@lifelogs.com> <87zl50jv52.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262497171 8379 80.91.229.12 (3 Jan 2010 05:39:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2010 05:39:31 +0000 (UTC) Cc: Ted Zlatanov , Phil Hagelberg , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 06:39:23 2010 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 1NRJBT-0003XW-90 for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2010 06:39:23 +0100 Original-Received: from localhost ([127.0.0.1]:43977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NRJBT-0000AE-QQ for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2010 00:39:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NRJBN-0000A3-S5 for emacs-devel@gnu.org; Sun, 03 Jan 2010 00:39:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NRJBH-00009K-DK for emacs-devel@gnu.org; Sun, 03 Jan 2010 00:39:16 -0500 Original-Received: from [199.232.76.173] (port=51956 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NRJBH-00009H-8L for emacs-devel@gnu.org; Sun, 03 Jan 2010 00:39:11 -0500 Original-Received: from caiajhbdcagg.dreamhost.com ([208.97.132.66]:40360 helo=homiemail-a17.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NRJBG-0003f6-Uy for emacs-devel@gnu.org; Sun, 03 Jan 2010 00:39:11 -0500 Original-Received: from enigma (71-23-19-98.war.clearwire-wmx.net [71.23.19.98]) (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 718537A805C; Sat, 2 Jan 2010 21:39:06 -0800 (PST) In-Reply-To: (Tom Tromey's message of "Fri, 01 Jan 2010 12:18:16 -0700") 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:119300 Archived-At: Tom Tromey writes: >>>>>> "Ted" == Ted Zlatanov writes: > 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. I agree that users should not need a DVCS installed on their system to use packages. However, leveraging a DVCS to get packages from their authors to a centralized listing seems like a really good idea. > 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. > > 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. I've actually been thinking in even more incremental steps. Installing package.el in Emacs without altering any of the existing Emacs code would be an easy first step and would give some immediate benefit in terms of packages that are not included in Emacs. The next step would be to work on package submission. If the centralized system has a list of packages mapped to a list of DVCS repositories, they could be polled periodically and all tags matching a certain convention (say, starting with "v" and followed by a dotted number series) would be treated as package. That version would then be processed and published to a downloadable location for clients to pull in. I wasn't thinking about integrating packages that Emacs already contains until after these steps were complete. One thing that may be infeasible but would certainly simplify things a lot would be if we spun off packages like org-mode into their own separate DVCS repository and removed them from the Emacs source tree before making package.el treat them as packages. However, this may cause some unwanted chaos; I don't want to barge in and create a lot of work for people. It might also imply that network access would be necessary to perform a full build of Emacs since it would have to download bundled packages at compilation time. Not sure if that is a serious problem. Anyway, I welcome thoughts on this. -Phil