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: Wed, 05 Sep 2007 18:14:53 -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 1189038979 26012 80.91.229.12 (6 Sep 2007 00:36:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2007 00:36:19 +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 Thu Sep 06 02:36:19 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 1IT5Ly-0001nU-Qe for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Sep 2007 02:36:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IT5Lx-00085d-1F for geh-help-gnu-emacs@m.gmane.org; Wed, 05 Sep 2007 20:36:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IT5Lc-00080A-KK for help-gnu-emacs@gnu.org; Wed, 05 Sep 2007 20:35:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IT5Lb-0007yK-Nw for help-gnu-emacs@gnu.org; Wed, 05 Sep 2007 20:35:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IT5Lb-0007y7-JT for help-gnu-emacs@gnu.org; Wed, 05 Sep 2007 20:35:51 -0400 Original-Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IT5Lb-0001Ox-7G for help-gnu-emacs@gnu.org; Wed, 05 Sep 2007 20:35:51 -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 l860Zon7005497; Wed, 5 Sep 2007 20:35:50 -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 l860ZnWo032635; Wed, 5 Sep 2007 20:35:49 -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 l860ZmjV016574; Wed, 5 Sep 2007 20:35:48 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 2F9E4C88484; Wed, 5 Sep 2007 18:14:53 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Drew Adams's message of "Mon\, 3 Sep 2007 16\:28\:02 -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:47262 Archived-At: >>>>> "Drew" == Drew Adams writes: Drew> If your concern is also about your site becoming infected, then Drew> perhaps this could be done on a different site - perhaps the Drew> wiki itself. My concern is that, if an automated approach becomes popular, then it is more worthwhile for people to try to slip in trojans. Of course there are no guarantees. But with ELPA I'm usually in touch with the authors, or I'm uploading an established package. With the Wiki there is little oversight. Even better would be some Debian-like web-of-trust thing, and package signing. But, that could come later I suppose, if needed. Drew> The ELPA version is likely to be stale, due to my laziness. Then that's another reason that ELPA is not a good match for your purposes. I don't think it is too valuable to users to host stale packages. Drew> But why the constraint that a package have an overall version number? Here is a (semi-) real example. ELPA includes EMMS. But, I've heard that someday EMMS will be included in Emacs. And, I suppose that EMMS will continue to be developed outside Emacs as well -- this is common for larger packages (gnus, erc, etc), especially because Emacs has a very slow release cycle. Suppose I install EMMS 3.0 now, then sometime later upgrade to Emacs 23 which (let's suppose) includes EMMS 3.1. How does package.el know which EMMS to use? This is the scenario I wanted to solve -- one that has bit me numerous times over the course of my Emacs life. Version numbers are a simple, conventional way to solve it. To continue the scenario, if EMMS 3.2 comes out, I can upload it to ELPA and folks can use it; and when they upgrade to Emacs 24 they won't have to do anything special. This isn't the only thing ELPA is good for, but it was one of the use cases I designed for. Drew> Why not separate this physical packaging from the logical Drew> packaging that is simply declaring the set of needed files? I thought about things like this. But, in the end I decided to try KISS as much as possible. And it turns out that most packages fit nicely into this approach. Drew> It would be great if an author could simply register a package Drew> description with your site, and have the site automatically Drew> periodically retrieve the requisite files from a specified Drew> source (which in my case would be Emacs Wiki). This opens the trojan door again. Also, IME it is rare for packages to be upload-ready. They typically don't follow the comment guidelines. Packages with dependencies on other packages need ELPA-specific comments as well. Your ideas are interesting though. I'm just not sure they would work that well in practice. E.g., I've looked through ELL numerous times. It is, unfortunately, full of broken links. That is something that is inevitable with a multi-site approach. Instead I was trying for something like "Ohio State Elisp Archive meets CPAN-ish trivial install". Drew> Maybe I'm missing the boat here. The package system doesn't Drew> actually install packages for the user, does it? It just makes Drew> them available for download, right? And it controls (checks) Drew> dependencies and maybe other potential consistency gotchas, Drew> right? Nope, it does download, dependency resolution (both at activation time and download time), and install. And deletion, too, whenever I get around to it. FWIW you can try out ELPA in just a couple minutes. There's an auto-installer on the web page. Run that, then: * M-x package-list-packages * "r" (re-reads the package list from ELPA) * "i" to mark for install, "x" to execute the installs I suggest 'bubbles' as a starter package. After it is installed, M-x bubbles. Drew> I can see why ELPA allows package versions, for example, but why Drew> would it require them for all packages it handles? Simplicity. Honestly I didn't consider that there would be a package without a version. Versioning is just, well, conventional and normal :). Drew> I figured it was only downloading. How does ELPA help a user install and Drew> compile? Do you provide make files etc. that one can use on various Drew> platforms, or how does it work? ELPA takes a very simple approach. It downloads the package and installs it in ~/.emacs.d/elpa/, then byte-compiles the .el files. It also extracts autoloads. If those things don't work, I simply don't upload the package. 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.) Activation means modifying load-path and evaluating the autoloads. If the package contains a 'dir' file, package.el also modifies the info path. >> * Automatically handle package dependencies Drew> Dependencies between packages or just among the files of a package? Between packages. E.g., lisppaste or weblogger require xml-rpc. If you install one of the former, the latter will be installed. Likewise for activation. One other big goal for ELPA was to take the pain out of installing Emacs Lisp packages -- to focus on the user experience. We certainly could write something "dumb" (not meaning that in a bad way) that simply downloads a .el and drops it somewhere. In my view this only solves part of the problem... dependencies matter too. So do some things not easily enforceable in a tool: does the package have autoload comments in place? Does it respect Emacs namespace rules? Key-binding rules? Etc. I do try to review packages for things like this before uploading (e.g., that is why quilt.el isn't there). So, part of the mission here is raising the standards for Emacs add-ons. Drew> Is it also OK if there is no notion of upgrading, for some package? Since version numbers are assumed, all upgrading means is, install a newer version. Anyway, I hope I've answered your questions. I didn't answer them all since I thought some of the answers would be redundant given other answers. If I missed something important I'm happy to talk and talk about ELPA :-) Tom