From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Integrating package.el Date: Thu, 04 Mar 2010 14:39:09 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r5nzkej6.fsf@lifelogs.com> References: <87wrzr6ugo.fsf@hagelb.org> <87ocl242jc.fsf@uwakimon.sk.tsukuba.ac.jp> <87d41ihx9g.fsf@stupidchicken.com> <87ocl167wx.fsf@hagelb.org> <8763795zsh.fsf@hagelb.org> <87r5pmwcf8.fsf@hagelb.org> <87ocjh2hyp.fsf@lifelogs.com> <31edf1081003032139t491b2339uf5202323100248c3@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1267753427 11598 80.91.229.12 (5 Mar 2010 01:43:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 5 Mar 2010 01:43:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 05 02:43:41 2010 connect(): Connection refused 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.69) (envelope-from ) id 1NnMD3-0000oV-Pu for ged-emacs-devel@m.gmane.org; Fri, 05 Mar 2010 02:20:10 +0100 Original-Received: from localhost ([127.0.0.1]:50197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NnMD2-0000GR-WF for ged-emacs-devel@m.gmane.org; Thu, 04 Mar 2010 20:20:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NnMCw-0000F4-Av for emacs-devel@gnu.org; Thu, 04 Mar 2010 20:20:02 -0500 Original-Received: from [140.186.70.92] (port=33203 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NnMCr-0000CN-MP for emacs-devel@gnu.org; Thu, 04 Mar 2010 20:20:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NnMCn-0006jE-3n for emacs-devel@gnu.org; Thu, 04 Mar 2010 20:19:57 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:51443) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NnMCm-0006il-Mj for emacs-devel@gnu.org; Thu, 04 Mar 2010 20:19:53 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NnIG1-0001gx-Lu for emacs-devel@gnu.org; Thu, 04 Mar 2010 22:06:57 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Mar 2010 22:06:57 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Mar 2010 22:06:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 71 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.91 (gnu/linux) Cancel-Lock: sha1:8tFqOGEyekZup5L6EU3eFA3OMu0= X-detected-operating-system: by eggs.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:121650 Archived-At: On Thu, 04 Mar 2010 13:29:49 -0500 Stefan Monnier wrote: SM> I want to be able to install all kinds of versions in a single spot SM> so I can quickly see which versions are available. This said, I SM> agree that allowing several install locations is desirable. SM> Actually the "install" part of the code should be able to install SM> a package *anywhere*. Similarly, the activation of a package SM> (i.e. setting up the autoloads) should be doable from a package located SM> anywhere. SM> It doesn't need to be part of the visible UI, but there should be SM> a command like M-x package-install that takes a file name (a single .el SM> file or a tarball) and a target directory (defaults to the main "install SM> location") and installs it there. SM> The only part that really needs to know about "install locations" is the SM> part that lets you list all the installed packages, deinstall some of SM> them, setup/remove activation for some of them, etc... On Thu, 04 Mar 2010 11:30:26 -0700 Tom Tromey wrote: Tom> You need multiple install locations to let package.el manage additions Tom> in site-lisp, and also (maybe -- there are some questions here) the Tom> load-path for packages which are included with Emacs but also released Tom> separately. Tom> So suppose Emacs starts up and sees, say, 3 versions of gnus: one Tom> included in Emacs, one in site-lisp, and one in ~/.emacs.d/elpa/. Tom> Which one should be activated? Tom> Right now the obvious answer would be the newest one -- but Stefan wants Tom> to let the user pick a specific one. So, I think we'll need a bit of Tom> additional metadata about this. How about letting the user define his own install location for each repository, but with a sensible default? The location could also be tagged with a "is it versioned?" boolean. While installing may not be possible into every location, the user will be able to activate whatever is installed in any location. For example: ELPA's Gnus defaults to ~/.emacs.d/elpa (from repository "ELPA", versioned to $location/gnus-x.yz ) Emacs' Gnus defaults to /usr/local/share/emacs/23.1/lisp (from repository "emacs 23.1", unversioned to $location/gnus) site's Gnus is set by user to /usr/local/share/oursite/lisp (from user-defined repository "oursite", unversioned to $location/gnus) So then "package-install" without a specific repository will pick the first repository in the package-archives list and try to write to it. If it fails, that's an error. Similarly for package removal. With a specific repository, both install and remove go to the specific location set by the user. Yes, unversioned install locations will cause conflicts, but they are necessary to make this backwards compatible. So then resolving the question of multiple installs will actually be "Do you want to pick the ELPA Gnus [in ...], the Emacs 23.1 Gnus [in ...], the oursite Gnus [in ...], or this CVS checkout we found in ~/gnus/lisp because it was in your load-path?" IOW, the user would choose between repository install locations (represented by the name of the repository) and unmanaged paths to resolve the conflict. Would that work? Ted