Re: Golang Xen packages and the golang packaging system

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

> BTW the separate repo isn’t off the table.  But there were some things other 
> Ian pointed out:

After trying (and failing) to get a go module with a remote import
path like `golang.xenproject.org/xenlight` defined in xen.git, I would
like to circle back to the separate repo.

In theory, modules are not supposed to be tightly coupled with vcs,
but in practice they are. It seems like you cannot define a module
with a remote import path without pointing to the repo *root*. I tried
many ways, but every attempt resulted in `go get enr0n.net/xenlight`
downloading the root of xen.git as the "module", while the actual
module in tools/golang/xenlight was excluded since it was seen as a
nested go module. If you want to get around these issues, I think you
would need to define your own module proxy. Or, we would need to just
give up on the "vanity" URL and use
`xenbits.xen.org/git-http/xen.git/tools/golang/xenlight` as the import
path.

For reference, I did get a test module `enr0n.net/xenlight` that
points to github.com/enr0n/xenlight working. That part is trivial if
you are able to point to the repo root.

Overall, between fighting with Go modules, tagging versions, and
making sure code is re-generated on IDL changes, it seems to me that
there are more negatives with putting the module in xen.git than there
are with putting the module in its own repo.

> 1. The GPL requires that you provide the “preferred form for modification” to 
> all the code.  I’m not sure this has been adjudicated in court, but there’s a 
> strong argument that *generated* code doesn’t match that criteria: that to 
> satisfy the GPL you’d need to include libxl_types.idl, idl.py, gengotypes.py, 
> and a Makefile suitable for tying them all together.  (Not that the 
> generation needs to be run with `go build`, but that ideally the 
> infrastructure would be there so that it *could* be run.)

Is there anything involved in solving this issue besides making sure
those files are copied to the repo in addition to the generated go
files? Or is there some concern in doing so?

> 2. Ian was concerned with how someone using the bindings would submit a patch 
> upstream.  Suppose someone cloned our “bindings” repo, made some changes so 
> that it worked for them, then wanted to submit the patch upstream.  How would 
> they do that?

I think we could mostly solve this with a good README explaining what
to do. It's not uncommon to see (a) generated Go code with // DO NOT
EDIT at the top, and (b) repos (mirrors) on github that do not accept
PRs. Or am I oversimplifying?

Thanks,
-NR