Machine-readable copyright module, take 2

[jsw at debian.org]

Hi Stuart,

On Tue, Sep 02, 2014 at 12:42:57AM +1000, Stuart Prescott wrote:
> Hi John,
> 
> It looks like this has come up really well. Thanks for your work on this.

Thanks for the review!

> One comment about the format specification URL is that there are now https 
> redirects in place so while the spec says "http://" the canonical URL isn't 
> really that any more. I suspect we should probably avoid flagging the https 
> version as an unknown version of the standard. For the purposes of python-
> debian, the most important thing is (normally) the ability to extract useful 
> data and not enforcing strictness. There are also tools like cme already in 
> existence to help lint and normalise the copyright files.

Agreed - I also didn't want the https:// URL to be considered unknown.
That probably was broken in the first patch set I sent, but it's in the
set of known formats in this one.  Can you take another quick look at
patch 4/12 in this series and tell me if it looks ok?

For what it's worth, so far no functionality is affected by the format
string.  At some point it might matter, e.g. if we want to look up
license text for a standard license (the names of which may change
between format versions), or if field meanings change over time
(hopefully not).  But since some of the draft versions of the format
have totally different syntax for e.g. the Files field, I thought it was
important at least to expose whether we know of a particular format.  If
you want, I can just leave the Header.format_is_known() method and
remove the actual warnings.

> It's nice to see an example of how to use the class too -- shall we ship 
> that in /u/s/d/python-debian/examples/?

Yes - see
http://lists.alioth.debian.org/pipermail/pkg-python-debian-maint/2014-August/001877.html

> (Looking at the RestrictedWrapper class, I should rework the removals.822 
> parsing to be based on that too rather than directly on Deb822, I guess)

It's up to you.  I like this way better but I'm admittedly biased. :)
It also is more flexible in case we later want to allow a richer
representation for a given field (it just needs a new property name, but
can share the same 822 field name with the old property name).

-- 
John Wright <jsw at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-python-debian-maint/attachments/20140901/fd27355a/attachment.sig>