[slime] swank-loader could use ASDF (#65)

[João Távora]

Helmut Eller <eller.helmut at gmail.com> writes:

>> In general, offloading some responsibilities to a software package that
>> specilize in them is a good policy in my opinion.
> Offloading stuff to ASDF doesn't sound much different from offloading
> stuff to quicklisp.

True. But still ASDF is common on many implementations systems while
Quicklisp isn't (yet) and skeptic coworkers, for instance, offer much
less resistance to the former.

But I'm also not necessarily opposed to recommending, bundling, or
installing quicklisp. The latter too seem a little out of SLIME's
jurisdiction though.

> Well, we don't need a default, one option for me, and a third option for
> the exotic cases.  Just put be in the exotic case.

Did you mean "put *me*" :) ?

Anyway I've noticed the :init argument to `slime-start' and the :init
keyword in `slime-lisp-implementations' is more than sufficient
abstraction to provide the two options rather cleanly. Even to disallow
ASDF loading in problematic implementations.

>  1. (asdf:load-system foo),
>  2. then had some load-time problem,
>  3. cleaned out the cache,
>  4. and magically (asdf:load-system foo) worked.

FWIW, though they are rare, I've recently found similar cache clearing
problems in vanilla slime as well: M-. would bring me to a correctly
named but empty file in some /tmp/slime-$PID dir. Clearing the slime
fasl cache did the trick. I don't know how to reproduce though.

> Or the "upgrade" stuff and Faré telling us how it fails in CMUCL and
> CCL.  None of this inspires trust.

Indeed

> But I recognize that the masses have spoken and ASDF is the de-facto
> standard.

Indeed++.

> All I'm saying is that M-x package-install is not that different from
> "make install".

Not needing to drop to a shell or running an external command is a big
usability difference.

    Emacs -Q
    M-x package-install RET slime-foo RET
    M-x slime

Notice no `slime-setup' to setup the foo contrib and its
dependencies.

That said I'm still *not* saying that the only way to do this is with
ASDF and without swank-loader.lisp. Indeed for (legitimate) cases of
mistrust, swank-loader.lisp could still be the default. But eventually
we should deprecate it.

>> At first sight, this would personally bug me: why not do this in the
>> user's .emacs in elisp? Why this file?
> Because reading .emacs from Common Lisp is difficult.  It's also much

Ahh, ok I get it finally, You want to read that file from the CL
side. That makes more sense. Still I don't like yet another file to
configure... I already have ~/.swank and ~/.emacs

> Also, storing per-project settings in a config file in the projects
> directory seems natural to me.  A single .emacs just doesn't work well
> for that.

Your case makes a bit more sense to me now I understand you want to read
from CL. But it is yet another file... :-(

Anyway recent emacsen have many mechanisms to manage per-project
configuration. "directory-local variables" are probably the simplest,
but very powerful already [1]. You do need emacs 24 though, but it is
already very easy to get in on debian stable. In emacs 23 you have to
bake your own, but it's easy too.

I must say I might have missed something but still don't understand how
per-project settings.

Maybe I don't understand which settings you want to set, and how many of
them relate to this discussion. But if your use case is avoiding getting
ASDF loaded into your image in some projects but not others, a
directory-localized `slime-lisp-implementations' and its existing
`:init' arg fit the bill rather nicely I think.

>> Also, if I understand correctly, this file would make ELPA (and el-get)
>> packaging much more complicated and non-standard.
> Not sure why that would be.

To be fair, though, you're right, *packaging* itself would not be
affected. But M-x package-install, IIUC is dedicated to installing and
activating a package by extracting autoload definitions for
functions. The autoloaded function, once run, slime could create your
default ~/.slime.d/config with the correct pathname of the
quicklisp.lisp also stored in a autoloaded variable.

>> I'm still confused. When don't we load it? BTW I think quicklisp
>> always loads ASDF.
> We could load quicklisp during "make install".  That's the time when you
> potentially need to download third party Common Lisp code.  E.g. when a
> contrib depends on cl-pcre.

I think those contribs could well depend on a slime-quicklisp contrib,
docstring being "Ensure quicklisp is available in the host lisp and
provide some convenience commands".

> We could also use it when a user wants to add a library to his
> project, e.g. we could have something like M-x slime-quickload.

A good command for that slime-quicklisp contrib, but something I would
keep out of core.

Anyway to summarize:

* in pull request #80 I'm working with Faré on a setup that uses
  ASDF/swank-loader.lisp per user defcustom. It is still somewhat
  crudely hacked, but I will iterate and make it cleaner.

* In trunk I've added a Makefile that creates elpa packages. They are
  not yet installable. As explained, it should be possible to allow
  these freer scheme without requiring ASDF at all. In a future pull
  request we can discuss this final ASDFless version and then decide if
  we pull in #80 as well.

João

[1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html