Re: user-controlled load-path extension: load-dir

[Mike Mattie <codermattie@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5562 bytes --]

On Mon, Mar 07, 2011 at 10:24:58AM -0600, Ted Zlatanov wrote:
> On Sat, 5 Mar 2011 11:11:34 -0800 Chad Brown <yandros@MIT.EDU> wrote: 
> 
> CB> On Mar 4, 2011, at 7:18 PM, Ted Zlatanov wrote:
> >> 
> >> By analogy consider some of the software that lets you put a snippet in
> >> a conf.d directory, obviously implying that this is convenient for the
> >> user.  This is just a sampling from my machine:
> 
> CB> Those are all machine-wide configurations.  For that, use site-lisp.
> 
> 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?
> 
> 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).
> 

This whole security thing is a real non-issue. There is no security in
Emacs, it (Emacs) simply uses the underlying system security
model. What is really at issue is whether the user _trusts_ the
code. Trying to address security issues in a software system that has
no security API/model leads to some skewed thinking, and I am not just
splitting hairs. Thinking in terms of trust leads to better reasoning.

> On Sat, 5 Mar 2011 23:21:51 -0800 Mike Mattie <codermattie@gmail.com> wrote: 
> 
> MM> There are ways to solve the problem you are looking at without wiring more
> MM> logic into Emacs. Use the .emacs file as a more sophisticated loader for a
> MM> complex configuration when necessary.
> 
> I can and do, sure.  I don't think it creates a nice user experience.
> 
> MM> I have done this with my Grail project (on EmacsWiki), as has tidyconfig.
> MM> I would look at these solutions first before proposing code that has to
> MM> be wired into the bootstrap codepath.
> 
> Thanks for pointing those out.  Would Grail or tidyconfig work as a core
> option on startup (meaning the user doesn't have to install a package,
> just customize a boolean)?  Do they handle signing the snippets the
> first time they are found?  Can you give us a comparison of them and any
> other similar solutions you know?  They have to be GPL and assigned to
> Emacs to be included.

I doubt Grail would be included in-tree. Maybe I am wrong, but I get that
vibe. I would certianly need to convert some recursive functions to iterative
versions before even bringing Grail to the table. I have been maturing Grail
out-of-tree to ensure the code is robust, designed well, and is targetted at
typical user needs.

> 
> MM> There are a number of issues a reliable loader should address:
> 
> MM> how does it handle errors ?
> 
> MM> how does it handle --batch ?
> 
> MM> how does it handle --daemon ?
> 
> MM> how simple,transparent,debuggable is the loader code ?
> 
> MM> I have not seen any code so far in your proposal unless I accidentally
> MM> skipped or deleted a message with it.
> 
> I can write the code but haven't seen the need for actual code yet (I
> could have just comitted some code to Emacs instead, but find that
> option to be antisocial).
> 
> I'd rather use something that already exists such as Grail or tidyconfig
> that you kindly pointed out.  If you could tell us how any potential
> solutions can help answer the questions above, that would be wonderful.
> I can look at any solutions and evaluate them if you like.

I can only speak for grail, but Grail essentially Handles the
load-path issue. When it comes to load-path Grail is
comprehensive. What grail does not do is automatically load code from
a given directory. Directories that grail looks for are added to
load-path when they exist. Grail looks for files such as keys.el
commands.el, user.el and does load those when found.  They are assumed
to be user created files. When snippets are collected in a directory
such as dist/elisp, or local/elisp, the user is expected to place a
require or similar command in one of these recognized files to
actually load the snippet/whatever at the start.

As far as error-handling goes grail does shine a bit in that errors within
a file are trapped, meaning that mistakes in one file does not cause the
entire configuration to abort leading to a --debug-init situtation. In this
regard Grail is extremely robust.

I will be updating the documentation of Grail extensively over the next couple
few days to describe it's use, usefulness, limitations etc .. I will send you
a mail off-list when I have articulated Grail properly.

> 
> To answer your questions 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 am seriously considering how to add the kind of functionality you want to
Grail. I would like to add it to broaden the usefullness of Grail. I do not
like the idea of hacking another load-path 'ish variable into Emacs when simply
adding elisp to manage load-path is an option. Two similar variables is simply
bad design.

> 
> Ted
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]