From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.help Subject: Re: ELPA and EmacsWiki Updates Date: Sun, 09 Sep 2007 11:06:31 -0600 Message-ID: References: Reply-To: tromey@redhat.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189361613 11171 80.91.229.12 (9 Sep 2007 18:13:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2007 18:13:33 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: "Drew Adams" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Sep 10 04:13:20 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IUY4V-000896-L5 for geh-help-gnu-emacs@m.gmane.org; Mon, 10 Sep 2007 03:28:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUQa9-0006dR-7I for geh-help-gnu-emacs@m.gmane.org; Sun, 09 Sep 2007 13:28:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUQZt-0006bp-Le for help-gnu-emacs@gnu.org; Sun, 09 Sep 2007 13:28:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUQZs-0006ao-Qs for help-gnu-emacs@gnu.org; Sun, 09 Sep 2007 13:28:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUQZs-0006aj-OM for help-gnu-emacs@gnu.org; Sun, 09 Sep 2007 13:28:08 -0400 Original-Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUQZs-0004hM-DH for help-gnu-emacs@gnu.org; Sun, 09 Sep 2007 13:28:08 -0400 Original-Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l89HS775006165; Sun, 9 Sep 2007 13:28:07 -0400 Original-Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l89HS7EP027204; Sun, 9 Sep 2007 13:28:07 -0400 Original-Received: from opsy.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l89HS65L017145; Sun, 9 Sep 2007 13:28:06 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 1A579378ABE; Sun, 9 Sep 2007 11:06:32 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Drew Adams's message of "Thu\, 6 Sep 2007 10\:00\:28 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux) X-Detected-Kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:47408 Archived-At: >>>>> "Drew" == Drew Adams writes: Drew> You might also consider hosting a list of "packages" or Drew> libraries that are not Elpable, with links to where to obtain Drew> them. [...] Drew> I'm guessing that you've considered this and decided against it, Drew> but I'll still make the suggestion ;-). :-). But yeah, we've got the wiki and ELL for this. Those do a pretty good job. Drew> That's clearly expressed, and I understand all that. My question Drew> is why impose version numbers on _all_ "packages" just to make Drew> them available at ELPA. IOW, the need for package versions for Drew> some packages does not imply such a need for all packages. Yeah, I suppose that's true. I will think about it some more. Drew> Again, I have nothing against adding "package-level" comments Drew> that are specific for ELPA. Drew> It would be preferable, of course, to do that in a form that Drew> could be used by multiple package systems, but perhaps it's not Drew> yet possible to standardize that. ELPA uses a few things already defined by the Emacs Lisp reference guide -- the Version header (though ELPA needs a specific form for the value) and the start- and end-comments. The start comment is used to extract the package description. ELPA also defines a couple new headers: Package-Version (in case Version has the wrong format) and Package-Requires. The latter is used to express dependencies. >> The auto-installer adds a line to your .emacs. When Emacs starts, >> package.el will do a dependency check and activate whatever packages >> it can. (So, e.g., you can change Emacs versions and things mostly >> still work.) Drew> Ouch! I don't want to tell you what to do or not do, but I don't Drew> much like the idea of something (even something I initiate) Drew> mucking with my .emacs. Anyway, that's another story, and I'm Drew> sure you have good reasons for doing it the way you do. Yeah. The goal of the auto-installer was to make it dead simple to start using ELPA. It is easy not to do this -- just don't run it :-). You can still use ELPA if you install package.el by hand and edit your .emacs, or whatever, yourself. Basically I thought it would be fun and worthwhile to make it so people could be running package.el in a few seconds without needing to know anything... since after all one of my goals for ELPA is to make it possible for folks who aren't emacs lisp wizards to run stuff -- not to mention removing the drudgery for those of us who can do it, but would just rather not :-) >> Activation means modifying load-path and evaluating the autoloads. If >> the package contains a 'dir' file, package.el also modifies the info >> path. Drew> Ouch again! Drew> I sure hope there is a foolproof way to uninstall - a way that Drew> backs out all of the automatic changes that you make to a user's Drew> environment. Been bit by this kind of "helper" tool too much to Drew> welcome it blindly. The load-path stuff is all done dynamically, when package-initialize is called at startup. To remove a package you can just "rm -rf" the directory in ~/.emacs.d/elpa/. Eventually I'll write package deletion support for the package menu mode. I've put it off. Unloading something after Emacs has started and package.el has initialized can't really work. Emacs just isn't good at this kind of thing. There's unload-feature these days, but even that won't undo the additions of autoloads and stuff. So, if you want to delete something you have to restart Emacs. That sucks from a UI point of view. I keep going back and forth on the question of package activation. Right now, if a package is installed, package.el tries to activate it at startup. But, we could store a preference so you can choose not to have some activated. One way this would be nice is if package.el was really widely used, including to install 3rd party elisp in a distro. Distros, in my view, have a problem where for most users they want to enable autoloads for all additional packages, but some power users want to turn off certain things. In this situation package.el would allow deactivating the uninteresting things. Anyway I'm not sure whether this is worth implementing. On the minus side it adds more complexity and UI. Tom