Recovering from yesterday's update

Yesterday's client update has a problem. If you upgrade from an existing installation, a critical file named client-info.sexp is missing. Its absence causes errors when trying to update again.

On SBCL, the error looks like this:

    error opening #P".../client-info.sexp":
      No such file or directory

On Clozure CL, it looks like this:

    > Error: No such file or directory : #P".../client-info.sexp"

Other implementations present similar error messages.

If you are encountering this problem, evaluate this:

(ql-http:fetch "http://beta.quicklisp.org/client/2014-01-28/client-info.sexp" (ql-setup:qmerge "client-info.sexp"))

If you aren't having any problems, there's no need to use this bit of code.

After fetching client-info.sexp, you should be able to evaluate (ql:update-client) without encountering any errors.

I've uploaded a fixed version of the client that compensates for the missing file, so future updates should not signal this missing file error. If you have any problems or issues with Quicklisp, please feel free to email me, email the mailing list, or discuss it on freenode #quicklisp.



Client update now available, and a bit of GPG

Client updates

edit There is a problem with the update. If you're having a problem related to client-info.sexp, I'll post a fix shortly. Sorry about the hassle!

The Quicklisp client updates I described last week are now part of Quicklisp. If you install Quicklisp from scratch with today you will be using the new client versioning system. To update an existing Quicklisp installation, use(ql:update-client).

This update provides several new options in quicklisp-quickstart:install:
  • :dist-url can be used to specify the initial dist version to use at installation time. Valid URLs can be obtained from an existing Quicklisp installation by evaluating one of the new functions (ql:dist-url "quicklisp") or (ql:available-dist-versions "quicklisp")
  • :client-url can be used to specify the initial client version to use at installation time. Valid URLs can be obtained from an existing Quicklisp installation by evaluating one of the new functions (ql:client-url) or (ql:available-client-versions)
There is also a new function, (ql:install-client :url url), that can be used to change the client version of an existing Quicklisp installation.

The ability to easily install (or go back to) a known-working client sets the stage for a pretty big Quicklisp client change. In the next few days I'm going to update Quicklisp to require ASDF 3, which it will fetch automatically if needed. If that change breaks your project, you will have a safety net: you can always go back to the previous version of the Quicklisp client. (If it breaks too many projects, Quicklisp itself will go back to a previous version of ASDF.)

If you have any trouble with this new Quicklisp setup, please let me know at xach@clozure.com. You can also discuss it on the mailing list or talk to me in realtime (if I'm around) in #quicklisp on freenode.

GPG signatures

I have created a new GPG key, release@quicklisp.org, for signing Quicklisp-related programs and metadata. You can get the key from various keyservers, i.e. "gpg --keyserver pgp.mit.edu --recv-keys 028B5FF7", or from http://beta.quicklisp.org/release-key.txt.

Here are some examples of signed files:
In general, if a the file at URL "http://beta.quicklisp.org/whatever" has a signature, it is the same URL with ".asc" appended, e.g. "http://beta.quicklisp.org/whatever.asc". If you fetch both files, you can verify the signature with "gpg --verify whatever.asc whatever".

The Quicklisp client code does not yet verify signatures, but you may use these signatures to independently verify the Quicklisp code and metadata you have fetched. A future Quicklisp update will provide more built-in cryptographic verification.



Consistent configuration with Quicklisp

I've been working on two new capabilities in Quicklisp. The default setup won't change, but there will be new options to use when you need them.

First, the quickstart process (downloading and loading quicklisp.lisp) will let you select exactly which dist to use at installation time.

If your project critically depends on the state of the Quicklisp library world from July, you can get your project development environment set up almost instantly with the correct version at installation time. (This was always possible after installation, but now you can skip a number of tedious manual steps.)

Second, you can also choose what version of the Quicklisp client software to use at installation time. You can also install an older version after initial installation.

This has been difficult to do in the past without saving the software and keeping track of it yourself. But now you can use a specific version with a simple option at installation time or a single function call after installation.

What are these capabilities for?

If you're starting a new project, it's reasonable to use the latest of everything – Quicklisp and libraries together. That's the default setup of Quicklisp. But the Quicklisp code and the libraries change over time. If you install Quicklisp fresh on another computer, or update Quicklisp on your original computer, it may bring different code and newer libraries that interact with your project in unexpected ways. It's good to have both an easy way to make a new install with a configuration consistent with your original installation, and a way to go back to that consistent configuration if an update goes wrong.

This work is nearly done, but needs some testing to knock off the rough edges. If you're interested in helping me test things out, please send me an email at xach@clozure.com. edit If you'd like to see the code, it's in the "versions" branches of https://github.com/quicklisp/quicklisp-client/ and https://github.com/quicklisp/quicklisp-bootstrap/.

The work has been supported by my employer, Clozure Associates. If you need Quicklisp support or enhancement, or have other Lisp consulting needs, get in touch!


January 2014 Quicklisp dist update now available

New projects: basic-binary-ipc, cl-bacteria, helambdap, lisp-unit2, pgloader.

Updated projects: access, asdf-dependency-grovel, asdf-package-system, buildapp, buildnode, caveman, cl-annot, cl-autowrap, cl-containers, cl-csv, cl-dbi, cl-emb, cl-enumeration, cl-erlang-term, cl-fbclient, cl-html-parse, cl-html5-parser, cl-inflector, cl-isaac, cl-libevent2, cl-memcached, cl-mustache, cl-ppcre, cl-project, cl-randist, cl-redis, cl-sam, cl-smtp, cl-test-more, cl-unification, cl-xul, clack, clem, clfswm, clinch, clsql-helper, collectors, com.informatimago, command-line-arguments, css-selectors, data-table, def-symbol-readmacro, deoxybyte-gzip, deoxybyte-io, deoxybyte-systems, deoxybyte-unix, deoxybyte-utilities, envy, esrap, exscribe, fare-quasiquote, flexi-streams, fset, function-cache, gbbopen, graph, group-by, http-parse, hunchentoot, hunchentoot-auth, hunchentoot-cgi, let-over-lambda, lisp-executable, lisp-interface-library, lisp-matrix, lisp-unit, lispbuilder, moptilities, more-conditions, new-op, ningle, nuclblog, portableaserve, postmodern, pzmq, qmynd, repl-utilities, rpm, sb-fastcgi, scribble, sha3, sxql, symbol-munger, vecto, vgplot, weblocks-stores, wookie, xarray, xhtmlambda, zs3.

There were more removed projects than usual this month. Here's a breakdown of what they are and why.

  • asdf-install was removed because I think the value in making old tutorials work has disappeared
  • cgn was removed because it no longer builds in SBCL and I am unable to find someone who can fix it
  • cl-cron was removed because its website disappeared and I was unable to contact the author about it
  • cl-prolog and cl-tokyo-cabinet were removed because an underlying library changed and broke them, and there was no response to an issue I opened
  • fare-matcher was removed at Fare's request; "Everyone should be using OPTIMA"
  • hunchentoot-vhost was removed because Cyrus said it's obsolete and there's no reason to keep publishing it
  • montezuma was removed because it doesn't build in SBCL and I am unable to find anyone who cares enough to fix it

This month marked the first time I made a pre-update dist available for testing, and it helped me find a number of issues before they made it into this "official" release.

Many thanks to Anton Vodonosov, Fare, and Dave Cooper for help and feedback when preparing the update this month. Any problems that remain are my fault.

To get the update, use: (ql:update-dist "quicklisp")


Invitation: promote a project

There are nearly a thousand projects in Quicklisp. Is there an important one you think is underappreciated or overlooked, despite its novelty, quality, or utility?

If you'd like to promote a Quicklisp-provided project on this blog, giving an overview of what it's for and how it might help accomplish something useful or interesting, please email me at zach@quicklisp.org for details.


A dist for testing

Last month I published a dist update when a few libraries weren't working well together. A few days later, after discussing things with the maintainers involved and crossing my fingers, I published a new dist update that worked better.

This month, I'm making a new dist under a different URL specifically for pre-release testing. If you want to test your project or library against the next update of Quicklisp, this is for you.

The test dist is called "qlalpha". It's available like so:

(in-package ql-dist)
(disable (dist "quicklisp"))
(install-dist "http://alpha.quicklisp.org/dist/qlalpha.txt" 
              :prompt nil :replace t) 

From then on, all updates will pull from the "qlalpha" dist, rather than the main "quicklisp" dist. You can use it with ql:quickload to load and test Quicklisp libraries.

To switch back:

(in-package ql-dist)
(disable (dist "qlalpha"))
(enable (dist "quicklisp"))

If you have any questions about how this works, or have any feedback about things that look likely to break in the next update, please feel free to discuss it on the Quicklisp mailing list.