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: Mon, 08 Mar 2010 11:53:34 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87wrxmg0o1.fsf@lifelogs.com> References: <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> <31edf1081003071516h522dcd31if96f7e96002bd3@mail.gmail.com> <876356hngn.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1268070846 22289 80.91.229.12 (8 Mar 2010 17:54:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Mar 2010 17:54:06 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 08 18:54:02 2010 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 1Noh9N-0007gh-SJ for ged-emacs-devel@m.gmane.org; Mon, 08 Mar 2010 18:53:54 +0100 Original-Received: from localhost ([127.0.0.1]:50129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Noh9N-0001Uu-Dm for ged-emacs-devel@m.gmane.org; Mon, 08 Mar 2010 12:53:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Noh9I-0001Tg-VD for emacs-devel@gnu.org; Mon, 08 Mar 2010 12:53:49 -0500 Original-Received: from [140.186.70.92] (port=47423 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Noh9I-0001Sy-3S for emacs-devel@gnu.org; Mon, 08 Mar 2010 12:53:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Noh9H-0001PG-E7 for emacs-devel@gnu.org; Mon, 08 Mar 2010 12:53:47 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:59260) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Noh9H-0001P7-2k for emacs-devel@gnu.org; Mon, 08 Mar 2010 12:53:47 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Noh9F-00074P-Ov for emacs-devel@gnu.org; Mon, 08 Mar 2010 18:53:45 +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 ; Mon, 08 Mar 2010 18:53:45 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Mar 2010 18:53:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 91 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:L0IOSOfUQNq2qEuw/ZHOZVENb+I= 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:121745 Archived-At: On Mon, 08 Mar 2010 12:01:52 -0500 Stefan Monnier wrote: Tom> I think the default should be to activate the most recent package, and Tom> to activate a package at install time. So, if the user picks a specific Tom> older version to activate (or equivalently deactivates the most recent Tom> version), record that, and take it into account during activation. >> So it's a version override alist, where a missing entry implies the user >> wants the latest? Do you mean something like this: >> ((package1 (repository1 path-to-specific-version1)) >> (package2 (repository2 path-to-specific-version2))) >> or am I misunderstanding something? SM> Don't know about you, but I seem to be missing something: why is the SM> word "repository" used here? AFAIK the "repository" for package.el are SM> (typically remote) locations from where to download packages, and they SM> should have no interaction whatsoever with the part that worries about SM> installation and activation of packages (just like Debian's dpkg has no SM> idea about repositories). I thought it made sense to remember the repository that a particular version came from, so selection (for activation) and warning messages are more helpful. But this can be guessed based on the path prefix so it's not strictly necessary, and you seem to be looking for package management that's less tied to repositories anyhow. So forget the above and see if the following makes sense. SM> BTW, my take on package activation and selection of versions (which IIRC SM> I already discussed with Tom a while back and we agreed to disagree) is SM> that activation of a package is controlled by lines in .emacs that take SM> a form similar to: SM> (load "/some/where/package/init/file.el" 'package) SM> so there is no search or selection of package version at startup-time. SM> This means that when a new version of a package is installed, Emacs has SM> various ways to react to it: SM> - don't do anything, and at the next startup warn the user that the SM> package he requested doesn't exist any more because it was replaced by SM> a new version. This warning is always necessary because packages can get removed by external agents as well (so the user doesn't know the load path is incorrect). So there could be no new version at all. SM> - update the "load" line right when the package gets upgraded (tho only SM> for the .emacs of the user that performs the upgrade). Too many potential problems here, I'd stay away from this. SM> - use symlinks like "/some/where/elisp/sml-mode" pointing to SM> "sml-mode-4.1" and use (load "/some/where/elisp/sml-mode/startup.el") SM> so the symlink can be adjusted during the upgrade. I did this for 7 years in a lab I was managing and it's not fun. You can automate some of the tedium but inevitably it becomes unwieldy. If the user or admin wants to do it this way, let them manage it externally, there are decent tools to automate it or they can write ELisp wrappers to fit their environment. Also symlinks don't work reliably in some environments. SM> - use a different load, like SM> (package-activate-latest "/some/where/elisp/sml-mode") SM> which will look for the latest sml-mode package installed in SM> /some/where/elisp/, or SM> (package-activate-latest "sml-mode") SM> which will look for the latest sml-mode package installed in SM> any of the installation targets. For the sake of backward compatibility this seems like the best option. (load) and (require) can keep working normally. Users can then transition to the package.el management gradually. Emacs can start using these options gradually too. Version overrides can be then specified as (package-activate-specific "sml-mode" "specific-version") (package-activate-specific "/path/to/sml-mode" "specific-version") Together with the startup warnings (which can be issued by package-activate-{specific,latest}) I think this approach makes sense. Ted