[asdf-devel] asdf loading error error

[Mark Evenson]

On 2/23/14, 17:27, Robert Goldman wrote:
> Faré wrote:
>> On Sat, Feb 22, 2014 at 3:26 PM, Cyrus Harmon <ch-lisp at bobobeach.com> wrote:
>>> While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error:
>>>
>>> Error while trying to load definition for system abcl-cdk from
>>> pathname /Users/sly/projects/abcl-cdk/abcl-cdk.asd:
>>>    There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION ASDF/SYSTEM:BUILTIN-SYSTEM-P {4DE3AFA9}> when called with arguments ((NIL)).
>>>    [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR]
>>>
>> There's an error while reporting a warning (warning about your system
>> having a bad version string).
>> I suggest you add this method in system.lisp after defclass system:
>>  (defmethod builtin-system-p ((x null)) nil)
>> Does it help?
>>
>> Robert, do you want me to commit that?
> 
> I'd like to understand this patch better before we push it.
> 
> Why is it that having a method on NIL is right?  Doesn't this just mask a bug where we are incorrectly treating NIL as if it's a system designator?
> 
> What's the cause for trying to ask if NIL is a built in system?  Presumably some system lookup returned NIL, right?  If so, why wasn't that trapped as an error?

The error is coming from the [ABCL-ASDF contrib which defines an
MVN-COMPONENT class descending from ASDF:COMPONENT][1].  This class is
used to represent a Maven dependency which is resolved to a binary JVM
artifact on the distributed Maven POM graph specified by three
coordinates:  GROUP-ID, ARTIFACT-ID, and VERSION.

In my implementation, I have (probably mistakenly) tried to overload the
ASDF:COMPONENT VERSION slot to contain a version inteligble to both
Maven and ASDF.  Unfortunately, the Maven version can basically contain
any string, not having a meaningfully defined ordering (i.e. you can
only determine if versions are different, not if one preceded another)
which conflicts with ASDF requirements for strict "semantic versioning"
(if I am using that term correctly).  In my defense, I think this was
working this way with ASDF 1, before ASDF 2's requirements came into being.

Currently, ABCL-ASDF "cheats" by stuffing a possibly non-conforming ASDF
version in the COMPONENT VERSION slot via the ASDF:ENSURE-MVN-VERSION
"cleanup" function, so that the form

   (:mvn "org.openscience.cdk/cdk-bundle" :version "1.5.6-SNAPSHOT")

produces this error while

    (:mvn "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT")

will correctly reference the correct Maven artifact, sneaking by ASDF's
checking for a valid version.

The right way forward would be to re-write the MVN-COMPONENT class not
to use the inherited VERSION slot, but another for its purposes.

But in the meantime, users get a baffling error when they use a non-ASDF
compliant slot value.


[1]:
http://abcl.org/trac/browser/trunk/abcl/contrib/abcl-asdf/abcl-asdf.lisp


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."