[asdf-devel] Problems with different versions of ASDF

[Faré]

If this is a big problem, we could add a -asdf3 or -a3 or such to the
name of the implementation string directory.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Better, faster, cheaper — pick any two.


On Wed, May 29, 2013 at 2:16 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> I have been running with ASDF from ACL and sometimes overloading it with
> ASDF from git.
>
> This gives me package errors like the following:
>
> ;   Fast loading
> /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf-context/set-context.fasl
> Error loading #P"/Users/rpg/clinit.cl": No package exists of name
> ASDF/LISP-ACTION.
>
> I suspect this happened because ASDF-context was compiled in an image
> with ASDF 3 loaded, and is being loaded in an image with ASDF 2.x
> (shipped by Franz with Allegro).
>
> Is there something I can do in systems that build on ASDF to avoid this
> from happening?
>
> Putting (:depends-on ASDF) in the relevant system (here my
> "asdf-context" system) does not solve the problem.
>
> It seems that we need a mechanism that says "if ASDF has changed its
> package structure, you must recompile."
>
> I understand the original motivation for subdividing the packages, but I
> think in future we need to be careful not to do this without an explicit
> plan to ensure it doesn't cause this kind of bug.
>
> It's an interesting unforeseen issue in the plan to be able to upgrade
> ASDF -- you need also to be able to downgrade!  I.e., if I want to be
> able to test new ASDF, I may still need to work with colleagues who are
> using an older, implementation-provided version.
>
> For now, I can simply blow away my cache, and I expect that will solve
> the problem, but it's something to consider.
>
> thanks,
> r
>
>
>