From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: ELPA and EmacsWiki Updates Date: Thu, 6 Sep 2007 10:00:28 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1189098118 8889 80.91.229.12 (6 Sep 2007 17:01:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2007 17:01:58 +0000 (UTC) To: Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 06 19:01:58 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 1ITKjN-0004Sz-HK for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Sep 2007 19:01:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITKjL-00086U-LB for geh-help-gnu-emacs@m.gmane.org; Thu, 06 Sep 2007 13:01:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ITKj6-000865-FK for help-gnu-emacs@gnu.org; Thu, 06 Sep 2007 13:01:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ITKj2-00085Z-Re for help-gnu-emacs@gnu.org; Thu, 06 Sep 2007 13:01:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITKj2-00085W-L8 for help-gnu-emacs@gnu.org; Thu, 06 Sep 2007 13:01:04 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ITKj2-0005NA-2R for help-gnu-emacs@gnu.org; Thu, 06 Sep 2007 13:01:04 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l86H11Ld009195 for ; Thu, 6 Sep 2007 12:01:01 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l86BdTn2028749 for ; Thu, 6 Sep 2007 11:01:01 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-203.us.oracle.com by acsmt350.oracle.com with ESMTP id 3189492271189098024; Thu, 06 Sep 2007 10:00:24 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 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:47287 Archived-At: > 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. I agree. On the other hand, some people will hear of ELPA and go to ELPA looking for packages. They won't necessarily know, for instance, to look for Icicles on Emacs Wiki. In that case, it could be helpful to make sure that ELPA has Icicles, even if it is not necessarily the latest and greatest. You might also consider hosting a list of "packages" or libraries that are not Elpable, with links to where to obtain them. Yes, those links will become outdated, but such a wide-ranging list could still help users. They might go first to ELPA looking for things, and it would then serve also as a directory of what is available. I'm guessing that you've considered this and decided against it, but I'll still make the suggestion ;-). > 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. That's clearly expressed, and I understand all that. My question is why impose version numbers on _all_ "packages" just to make them available at ELPA. IOW, the need for package versions for some packages does not imply such a need for all packages. You have a high standard for packages. You might consider also having a lower standard with correspondingly less ELPA support, thus allowing lighter weight packages to benefit from some of what ELPA offers. I'm thinking of both users and authors here - not every library needs to be a buttoned-down package at the level you've defined it, IMO. What's appropriate for a large, communal project is not necessarily also appropriate for a simple but perhaps multi-file library. > 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. I understand. I have no idea how much work would be involved in an approach such as I suggested. It's just something that seems good to me from the point of view of users and authors - for at least some (e.g. simple) packages. > 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. Again, I have nothing against adding "package-level" comments that are specific for ELPA. It would be preferable, of course, to do that in a form that could be used by multiple package systems, but perhaps it's not yet possible to standardize that. I personally don't want to get into one format for ELPA, another for GNU Emacs, another for ELL, and so on. But that's life, I guess. > 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". I too used to use OSELA, until it fell off the edge of the Earth. > 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. OK, will do. > 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 > :). So call me unconventional and abnormal ;-). > 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.) Ouch! I don't want to tell you what to do or not do, but I don't much like the idea of something (even something I initiate) mucking with my .emacs. Anyway, that's another story, and I'm sure you have good reasons for doing it the way you do. > Activation means modifying load-path and evaluating the autoloads. If > the package contains a 'dir' file, package.el also modifies the info > path. Ouch again! I sure hope there is a foolproof way to uninstall - a way that backs out all of the automatic changes that you make to a user's environment. Been bit by this kind of "helper" tool too much to welcome it blindly. > >> * 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. Please consider not necessarily raising the standards for all Emacs add-ons to the same level. Not every contribution needs to be at your level of "packageness", IMO. > 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. Right. I meant is it OK if there is no notion of version number. The answer seems to be no. > 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 :-) Yes, thanks.