Helmut Eller eller.helmut@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.
- (asdf:load-system foo),
- then had some load-time problem,
- cleaned out the cache,
- 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...