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

[Helmut Eller]

On Tue, Jan 07 2014, João Távora wrote:

[...]
>> So you say that's a clear advantage?  Well, I still clear out ASDF's
>> fasl cache regularly because I don't trust ASDF.  And I rather debug the
>> code in swank-loader.lisp than in asdf.lisp.
>
> Yes, it seems like an advantage. Well I understand your point about
> debugging a familiar swank-loader.lisp, it's not so for others
> (i.e. co-workers not managing to get a contrib loaded or understanding
> why swank error'ed out and quit their Allegro suddently). ASDF offers
> good error messages and restarts, which are already familiar if you're
> in the quicklisp/asdf ecosystem.
>
> 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.

> In my view `slime-init-command' should keep "returning a string to
> initialize lisp", as per its docstrings. But that string, by customizing
> a variable:
>
> * should, be default, be built around applying ASDF:REQUIRE-SYSTEM to
>   :SWANK and/or whatever contribs the user has set up.
>
> * could be based on loading swank-loader.lisp from the current
>   directory, which is the current case.
>
> * could be based on some custom swank-loading-logic if the user decides
>   so.
>
> Maybe we coulnd move the current swank-loader.lisp to
> swank-asdfless-loader.lisp and load it as per a `defcustom' that you
> enable in your config?

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.

> Still, I'm curious as to why you don't you trust ASDF? Any specific
> problems in mind?

As I said in a another message, I had experiences like this:

 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.
 
Or just a few days ago:

 This is SBCL 1.1.12-1.fc20, an implementation of ANSI Common Lisp.
 ...
 * (require :asdf)
 * (uiop:with-temporary-file (:stream s) s)

 debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread
 #<THREAD "main thread" RUNNING {AC17981}>:
   Couldn't remove "/tmp/tmp9MFH86" while closing #<SB-SYS:FD-STREAM
                                                      for "file /tmp/tmp9MFH86"
                                                    {BAD9B51}>:
  No such file or directory

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

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

>> I would say ELPA packages must be installed and the user "makes" .elc
>> files.
>
> I don't undertand this bit. ELPA packages are uploaded by the developers
> onto remote repositories and fetched-and-installed via package.el's
> `package-install' command.
>
> They can/should be built by us using a make target that picks out some
> files from the source repo, auto-generates others like
> slime-pkg.el. package-install then autogenerates a slime-autoloads.el
> file and byte compiles the remaining ones, sets up load paths and all
> that.

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

>> Assume we know how to load quicklisp. Let's say the user needs to create
>> a config file, ~/.slime/config, that looks like so:
>>
>> (:load-quicklisp-form (cl-user:load-quicklisp)
>>  :load-asdf-form (require :asdf)
>>  :slime-contribs (slime-repl slime-foo))
>
> 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
easier to automatically update a config file that contains only
"declarative" stuff and no general Lisp code.  And why would you put
information about quicklisp into your .emacs in the first place?  I
could understand .sbclrc or .swank.lisp.

> very few EMACS packages have
> their own config files (I can think of Gnus only) and they are all
> emacs-lisp, so that they can be perfectly replaced with elisp code in
> user's init files. I would see no advantage in adding one such file
> to SLIME.

The requirements of most Emacs packages are quite different.  Few Emacs
packages ship substantial non-Emacs-Lisp source code around and have to
initialize half a dozen different interpreters each with different
command line arguments etc.

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.

> 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 clear. I'm not adding a ASDF dependency to slime so that we get
> ASDF in the lisp runtime, although that is a side effect, unless we go
> to some lengths to delete the packages afterwards.
>
> I'm adding it because it's becoming a standard and is specilized in
> representing dependencies between systems, which is something we can
> definitely use to simplify out loading behaviour:
>
> * to make addition of third-party contribs easier;
>
> * to ease bundling our own existing contribs in separate packages;
>
> * to have "one" way of loading swank, less 300 lines to maintain, and
>   one less option-hungry SWANK-LOADER:INIT to worry about.
>
> Once we have a simple enough loading behaviour, it's much easier to add
> installation behaviours that serve:
>
> * your "make install" use case
> * the hacker's clone-my-own case
> * ELPA's package-install <some-package-depending-on-slime>
> * el-get
>
>> we know how to load quicklisp but doesn't mean we load it all the
>> time.
>
> 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.  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.

Helmut