Metadata check [WAS Re: How would you feel...]

Robert P. Goldman rpgoldman at sift.net
Thu May 28 13:01:24 UTC 2015


Erik Huelsmann wrote:
> Hi,
> 
> In various occasions I have seen that you plan to make the metadata
> arbitrary string or even general values. While I think that's okay, to
> provide lists of suggested values so that use of the values gets easier
> and if most people use the suggested values, the value system could end
> up centralized around those values. In my opinion, that would add value,
> especially for machine interpretation.

Note that this isn't something that I have planned. It is something that
is the de facto current standard.  To date, all the metadata are given
simply as strings, and they aren't of use for other than human inspection.

If someone would suggest a list of keywords for the licenses, we could
certainly incorporate that in some fashion.  But it would complicate any
introspection code.  Presumably that code would be taking the metadata
and formatting it for the user.  So it would now have to consider the
possibility of keywords, which should be translated, and probably lists
of keywords (per Fare's email), as well as strings.  That would
complicate the work of anyone trying to make use of the code.

Now, if there was something where someone might want to say:

(find :gnu-gpl (mapcar #'asdf:component-license my-systems))

[actually, that wouldn't work because of the possibility
component-license is list valued]

and do something with the results, then it might be worth making such an
effort.  But I haven't seen any "pull" for such a feature in ASDF.

cheers,
r


> 
> Regards
> 
> Erik
> 
> On May 27, 2015 8:54 PM, "Robert P. Goldman" <rpgoldman at sift.net
> <mailto:rpgoldman at sift.net>> wrote:
> 
>     Faré wrote:
>     >> OTOH, it's probably A Bad Thing if you depend on a system for
>     something
>     >> you are doing, and don't know what license it uses.
>     >>
>     > Well, we haven't codified any format for :license. I suppose we
>     could adopt
>     > the nomenclature used by Debian. Except what in Lisp circles goes by
>     > the name "MIT"
>     > (as notably used by ASDF itself) in Debian-speak is called "Expat".
>     > Also, we don't have a story for multi-licensed code either.
>     > For instance, I have code under LLGPL or bugroff, or BSD or bugroff.
> 
>     I didn't mean that we needed a codified format.  I just meant that if
>     you are using a system, and the humans involved don't know if your usage
>     is legal (e.g., are you using pure GPL in a commercial application? are
>     you delivering source for libraries when you deliver your code? etc.),
>     that's a Bad Thing.
> 
>     Given that :LICENSE is currently arbitrary string valued, we can just
>     make a string that indicates multiple possible licenses.
> 
>     We could certainly add some standard values (keywords?) for common
>     licenses, and allow people to specify a list of such values (and an
>     optional string), but I'm not sure what we would gain by this.
> 
>     I don't yet see a use case for machine-introspection on the :license,
>     but I'm open to suggestions.
> 
>     >
>     >> But that's why I created a special class of CONDITION for this
>     case --
>     >> so you can muffle it if you don't care.  It would be nice if
>     there was
>     >> some way to detect the distinction between internal systems (fix
>     them!)
>     >> and external systems (muffle).
>     >>
>     > At ITA, we started with muffling the external systems, but quickly
>     > enough decided to fix them instead; code quality matters for libraries
>     > we depend on, too. But we did have a list of style-warnings to muffle
>     > and some of them were based on dependencies indeed.
> 
>     For now a programmer could match the name of the system in my
>     MISSING-METADATA condition, and use that to make his or her decision
>     about muffling.
>     >
>     >> I'll push my topic branch today.  It needs a test script, and I'd
>     like
>     >> to make it skip signaling on "slashy" subordinate systems, but
>     I'd love
>     >> comments in the meantime.
>     >>
> 
>     I pushed this as the QL-metadata-warning topic branch.
> 
>     Best,
>     r
> 




More information about the asdf-devel mailing list