[asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25
Hi, There is an outstanding request from the maintainer to test the latest asdf "in production," and I'm here trying to do that. So what do I have to do in order to make (asdf:system-source-directory :uiop) still work after upgrading asdf? Is it a bug that after upgrading from 3.0.2.3 (the current ASDF shipping with fully patched Allegro) to 3.0.2.25, then (uiop:system-source-directory :uiop) returns nil? Before upgrading, it returns the uiop-3.0.2.4/ in the quicklisp/dists/quicklisp/software directory. After upgrading, it returns nil. The impact of this in production is that I am trying to make a monolithic fasl of a system which depends on :uiop, and the :uiop module is not getting included in this monofasl. This of course results in "package missing" errors when trying to load this monofasl into a vanilla image to do a build. The way I install asdf 3.0.2.25 for trying to use it in production is: 1. git pull into my local asdf directory. 2. make (to make a single asdf.lisp file in asdf/build/) 3. copy this to quicklisp/asdf.lisp 4. rm -r quicklisp/cache 5. edit quicklisp/setup.lisp to say: (defvar *required-asdf-version* "3.0.2.25") 6. copy the uiop/ directory from local asdf/ into quicklisp/local-projects/ 7. restart the Lisp 8. load quicklisp/setup.lisp and (ql:register-local-projects) Having done all this, the (asdf:system-source-directory :uiop) still returns nil, and uiop is not ending up in my monofasls which depend on it. Am I doing it wrong? My Best, Dave
On Wed, Oct 16, 2013 at 1:42 AM, Dave Cooper <david.cooper@genworks.com> wrote:
Hi,
There is an outstanding request from the maintainer to test the latest asdf "in production," and I'm here trying to do that.
So what do I have to do in order to make
(asdf:system-source-directory :uiop)
still work after upgrading asdf?
General remarks:One limitation of the ASDF upgrade process is that extensions often stop working after upgrade, and need to be reloaded. You may have to upgrade ASDF *before* you load quicklisp, and/or re-load quicklisp (and all other extensions) after you upgrade ASDF. That is why I recommend upgrading ASDF as the very first step in any installation: It's a no-op if no upgrade is available, and a lifesaver is one is. As to UIOP, I disrecommend using a version of UIOP older than ASDF. If you upgrade to the latest ASDF, don't use an older UIOP from quicklisp (that said, if you do the upgrade right, your own ASDF & UIOP should shadow those from quicklisp, and/or you should ) Now I'm looking at your detailed explanations:
Is it a bug that after upgrading from 3.0.2.3 (the current ASDF shipping with fully patched Allegro) to 3.0.2.25, then
(uiop:system-source-directory :uiop)
returns nil?
Did you actually load the ASDF from Allegro at some point in the same image?
Before upgrading, it returns the uiop-3.0.2.4/ in the quicklisp/dists/quicklisp/software directory. After upgrading, it returns nil.
Does the upgrade happen after or before you load quicklisp? Does quicklisp work at all after the upgrade?
The impact of this in production is that I am trying to make a monolithic fasl of a system which depends on :uiop, and the :uiop module is not getting included in this monofasl. This of course results in "package missing" errors when trying to load this monofasl into a vanilla image to do a build.
The way I install asdf 3.0.2.25 for trying to use it in production is:
1. git pull into my local asdf directory. 2. make (to make a single asdf.lisp file in asdf/build/) 3. copy this to quicklisp/asdf.lisp 4. rm -r quicklisp/cache 5. edit quicklisp/setup.lisp to say: (defvar *required-asdf-version* "3.0.2.25") 6. copy the uiop/ directory from local asdf/ into quicklisp/local-projects/ 7. restart the Lisp 8. load quicklisp/setup.lisp and (ql:register-local-projects)
Having done all this, the (asdf:system-source-directory :uiop) still returns nil, and uiop is not ending up in my monofasls which depend on it.
Am I doing it wrong?
It looks right, or at least defensible. Did you copy the contents of version.lisp-expr in uiop/ or a symlink that's now dangling? That could make a difference, though I would expect a more noisy failure. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are three types of people in the world; those who can count, and those who can't.
The way I install asdf 3.0.2.25 for trying to use it in production is:
1. git pull into my local asdf directory. 2. make (to make a single asdf.lisp file in asdf/build/) 3. copy this to quicklisp/asdf.lisp 4. rm -r quicklisp/cache 5. edit quicklisp/setup.lisp to say: (defvar *required-asdf-version* "3.0.2.25") 6. copy the uiop/ directory from local asdf/ into
quicklisp/local-projects/
7. restart the Lisp 8. load quicklisp/setup.lisp and (ql:register-local-projects)
Having done all this, the (asdf:system-source-directory :uiop) still returns nil, and uiop is not ending up in my monofasls which depend on it.
Am I doing it wrong?
It looks right, or at least defensible. Did you copy the contents of version.lisp-expr in uiop/ or a symlink that's now dangling? That could make a difference, though I would expect a more noisy failure.
So I went ahead and tried (load (compile-file "quicklisp/asdf.lisp")) before loading quicklisp/setup.lisp. And yes, I copied version.lisp.expr into quicklisp/local-projects/uiop/. To test that it wasn't ignoring the uiop in local-projects because it is the same version as what is already loaded, I even temporarily bumped the version number in that version.lisp-expr to 3.0.2.33. Still no dice -- I still get (asdf:system-source-directory :uiop) --> nil after loading the quicklisp/setup.lisp and (ql:register-local-projects) Quicklisp works in general after the upgrade. It just can't find the source directory (or any source directory) for :uiop. It's not crucial that I release with this latest 3.0.2.32, but I just bring up this issue in case it is actually a lurking asdf bug which needs to be shaken out before 3.0.3 release... -- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype)
So I went ahead and tried
(load (compile-file "quicklisp/asdf.lisp"))
before loading quicklisp/setup.lisp.
If you already changed the quicklisp copy and *required-asdf-version* to something later than your implementation-provided ones, as I believe you are, this step is redundant.
And yes, I copied version.lisp.expr into quicklisp/local-projects/uiop/.
Did you use cp -aL with -L to dereference the symlink? It worked for me.
To test that it wasn't ignoring the uiop in local-projects because it is the same version as what is already loaded, I even temporarily bumped the version number in that version.lisp-expr to 3.0.2.33.
No, I don't think it's magically checking the version against downgrade, as it is doing for asdf itself. Maybe it should? CL_SOURCE_REGISTRY=~/cl/poiu rlwrap sbcl --eval "'(#.(map () 'require '(:asdf :poiu)) #.(in-package :asdf) #.(load \"~/quicklisp/setup\"))" * (system-source-directory :uiop) #P"/home/tunes/quicklisp/local-projects/uiop/" I didn't even have to (ql:register-local-projects) in that session — or maybe its effects were persistent across section? Looking at the source, it builds an index, so you need to run it once after you installed the copy of uiop, and thereafter its effects should persist.
Still no dice -- I still get
(asdf:system-source-directory :uiop) --> nil
after loading the quicklisp/setup.lisp and (ql:register-local-projects)
Quicklisp works in general after the upgrade. It just can't find the source directory (or any source directory) for :uiop.
It's not crucial that I release with this latest 3.0.2.32, but I just bring up this issue in case it is actually a lurking asdf bug which needs to be shaken out before 3.0.3 release...
If something is broken, we definitely want to solve before release. But I fear the problem is with your configuration somehow. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What one person receives without working for, another person must work for without receiving. — Adrian Rogers
participants (2)
-
Dave Cooper -
Faré