Closed j3pic closed 6 years ago
I'm having the same problem on Clozure Common Lisp Version 1.11.5/v1.11.5 (LinuxX8664).
remote: ccl now installed
remote: Version 1.11.5/v1.11.5 (LinuxX8664)
...
remote: ==================================================
remote: 838 bytes in 0.00 seconds (1389.40KB/sec)
remote: ; Fetching #<URL "http://beta.quicklisp.org/client/2017-03-06/quicklisp.tar">
remote: ; 250.00KB
remote: ==================================================
remote: 256,000 bytes in 0.00 seconds (54100.84KB/sec)
remote: ; Fetching #<URL "http://beta.quicklisp.org/client/2015-09-24/setup.lisp">
remote: ; 4.94KB
remote: ==================================================
remote: 5,054 bytes in 0.00 seconds (8658.85KB/sec)
remote: ; Fetching #<URL "http://beta.quicklisp.org/asdf/2.26/asdf.lisp">
remote: ; 194.07KB
remote: ==================================================
...
remote: ==================================================
remote: 218,697 bytes in 0.01 seconds (31551.38KB/sec)
remote: ; Loading "hunchentoot"
remote: > Error: Error while trying to load definition for system bordeaux-threads from pathname /app/tmp/cache/quicklisp/dists/quicklisp/software/bordeaux-threads-v0.8.5/bordeaux-threads.asd: You need ASDF >= 3.1 to load this system correctly.
This is preventing me from updating a CCL-based Heroku buildpack to work with the latest Heroku stack and CCL. It's a pity because the ability to deploy Common Lisp apps to Heroku would be amazeballs.
Sorry, Quicklisp will not be distributing a new ASDF any time soon. The version provided with your implementation is the one to use - if it's too old, please follow up with the implementation instead.
What's preventing Quicklisp from distributing a newer ASDF?
I agree with @Hexstream . Getting all the implementors to shape up is much more difficult than just having the QL installer handle everything. Multiply that difficulty by the difficulty of getting all the Linux distros to distribute the latest versions of everything. My Travis CI test will have to continue explicitly patching ASDF until Ubuntu catches up.
If Quicklisp provides the latest ASDF 3.x, it will push forward what many users get by default, and I do not want to force people to use something that has in my experience been buggy. I think it was a mistake for Quicklisp to push ASDF 2 forward back in the day, and it's something I don't want to repeat.
If you require a specific recent version of ASDF for a project, make its asdf.lisp part of the project.
In fact, I'm much more likely to drop the fallback ASDF support entirely, which provides a pretty-old ASDF, than to push a recent version of ASDF.
I see. Thanks for the info.
@j3pic Sorry, I could have been clearer. I was merely asking for background information that I was interested in and thought might be of general interest, not contesting the decision. Generally I like to know the "why" of things and appreciate when that is proactively provided, at least in broad strokes.
@xach Thanks for the suggestion. I have added an ASDF 3 asdf.lisp
to my project and verified that it works.
@quicklisp Thanks for the clarification. I switched to Roswell for my environment setup in CI, and that pulls down a newer version of ASDF.
I ran into trouble building CLOSER-MOP because one of its dependencies uses a feature of ASDF not found in the version shipped with QL. The problem does not affect builds with CL implementations that provide a new enough version, but I've seen this problem using the Ubuntu Trusty version of SBCL (which is version 1.1.14).