From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chad Brown Newsgroups: gmane.emacs.devel Subject: Re: user-controlled load-path extension: load-dir Date: Mon, 7 Mar 2011 09:18:44 -0800 Message-ID: References: <87ei6mz24h.fsf@lifelogs.com> <20110306072147.GA11067@event-horizon.homenet> <871v2i525h.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1299518449 19000 80.91.229.12 (7 Mar 2011 17:20:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2011 17:20:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 07 18:20:45 2011 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 1Pwe6s-0001Tb-Pl for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2011 18:20:43 +0100 Original-Received: from localhost ([127.0.0.1]:35871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwe6s-0002St-90 for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2011 12:20:42 -0500 Original-Received: from [140.186.70.92] (port=56767 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwe5B-0001eY-Fn for emacs-devel@gnu.org; Mon, 07 Mar 2011 12:18:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwe54-0002ba-70 for emacs-devel@gnu.org; Mon, 07 Mar 2011 12:18:56 -0500 Original-Received: from dmz-mailsec-scanner-8.mit.edu ([18.7.68.37]:50978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwe54-0002bU-4x for emacs-devel@gnu.org; Mon, 07 Mar 2011 12:18:50 -0500 X-AuditID: 12074425-b7c98ae000000a04-dc-4d75137902f0 Original-Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id F7.DD.02564.973157D4; Mon, 7 Mar 2011 12:18:49 -0500 (EST) Original-Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p27HIm5o000758; Mon, 7 Mar 2011 12:18:49 -0500 Original-Received: from [10.0.1.3] (c-67-183-32-38.hsd1.wa.comcast.net [67.183.32.38]) (authenticated bits=0) (User authenticated as yandros@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p27HIjnn023757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Mar 2011 12:18:46 -0500 (EST) In-Reply-To: <871v2i525h.fsf@lifelogs.com> X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAARePPVM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 18.7.68.37 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:136839 Archived-At: On Mar 7, 2011, at 8:24 AM, Ted Zlatanov wrote: > Bazaar has a plugins directory; files in it are automatically activated, > as an example of a user-level facility like this. Anyhow, my point is > that placing a file in a directory is inherently more modular and > convenient to the user than augmenting a single file. Do you disagree? My point is that the user must take an explicit step to do either, and that placing a file in a magic directory and then answering questions about it (both steps are required) is significantly less convenient and equally or less modular than running an installer command. So, yes, I do disagree. What you call `augmenting a single file' can be done with a simple, user-fiendly lisp command. The simple combination of el-get and package.el is much of the way there today. > CB> If the user has to go through a set of steps to install and activate a > CB> package, how isn't that what ELPA does? > > They are not packages, they are snippets of code. ELPA requires far > more structure and many more steps. For what I'm proposing, a lot less > work is required (just a y/n prompt the first time a snippet is found to > ensure it's not placed there maliciously). > [...] from my perspective, IMHO a loader should work > like package.el. IOW, whenever and however package.el is loaded > currently, this loader we're discussing should also be loaded, since > it's effectively a package manager but with snippets instead of > packages. I think that you're conflating package.el with the (still developing) policy concerning the management of the `official' central archive for it once it's included by default. You say that you want something that `should work like package.el', but I don't see where you say what your problem with package.el is except to imply that you think some sort of overhead will be too high. I honestly doubt that there is a lot more effort required to create something that works with package.el than there is to make a snippet that works automatically with just a simple mechanical checksum test. Put another way: I doubt that the overhead is likely to be too high for anyone who's actually creating something that wants to be shared automatically. Put another another way, I think that the snippet of code that can't be a package or in site-lisp but that several users want to share and use automatically is really unlikely to exist. Maybe you could take a look at package.el start with http://tromey.com/elpa/faq.html and describe what you think is too much effort? Package.el will be included with emacs, can be (is being?) developed to make it more user-friendly, and doesn't have the security issues of the magic directory. *Chad