From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Bundling GNU ELPA packages Date: Thu, 06 Nov 2014 18:02:22 -0500 Message-ID: References: <877fz8ktio.fsf@Rainer.invalid> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415314980 6722 80.91.229.3 (6 Nov 2014 23:03:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2014 23:03:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 07 00:02:52 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XmW4q-0006rI-AS for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 00:02:52 +0100 Original-Received: from localhost ([::1]:56513 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmW4p-0006HR-Uj for ged-emacs-devel@m.gmane.org; Thu, 06 Nov 2014 18:02:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmW4W-0006H4-8g for emacs-devel@gnu.org; Thu, 06 Nov 2014 18:02:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmW4O-0006Sg-QF for emacs-devel@gnu.org; Thu, 06 Nov 2014 18:02:32 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:60498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmW4O-0006Ql-M1 for emacs-devel@gnu.org; Thu, 06 Nov 2014 18:02:24 -0500 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id sA6N2MFG002210; Thu, 6 Nov 2014 18:02:23 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id ADB4D66125; Thu, 6 Nov 2014 18:02:22 -0500 (EST) In-Reply-To: <877fz8ktio.fsf@Rainer.invalid> (Achim Gratz's message of "Thu, 06 Nov 2014 20:39:59 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5117=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5117> : inlines <1498> : streams <1337168> : uri <1833026> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176493 Archived-At: > I do. Depending on the exact timing of the change I may have more or > less time to spend on this topic, though. Any time now would be good. > Here's one issue that I've not seen discussed bradly so far: currently > builtin packages aren't packages at all and are indeed available > site-wide for this particular Emacs version. ELPA packages on the other > hand are a per-user thing only. With ELPA packages bundled into Emacs, > I suggest that there should be a possibility for site-wide configuration > of which packages are available and enabled in the same way that > site-lisp currently works for non-packaged libraries. While there is no UI for it, package.el can definitely handle site-wide packages: just add the corresponding directory to package-directory-list. And /usr/local/share/emacs/site-lisp/elpa is included in there by default. I'm not sure exactly what kind of "configuration of which packages are available" you're thinking of, but I don't plan to provide a way to "disable" bundled packages, just like we currently don't offer a way to disable the things "activated" in lisp/loaddefs.el. Elsewhere some other people talked about: > > CEDET also comes to mind as a great candidate, although it might be > > harder to move. > I think the Big Three are good candidates: Org, Gnus, and CEDET. Once the infrastructure is in place, we will have the opportunity to look at those things. Note that Gnus is probably not an easy option since several parts of it are also used by non-Gnus code (e.g. message.el for bug reports). Stefan