emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chad Brown
Subject: Re: user-controlled load-path extension: load-dir
Date: Mon, 7 Mar 2011 09:18:44 -0800

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]