On Wed, Oct 27, 2021 at 6:18 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
Currently we have 3 go modules:
-
github.com/ovirt/go-ovirt
https://github.com/oVirt/go-ovirt/
seems that this repo generated by
https://github.com/oVirt/ovirt-engine-sdk-go
-
github.com/ovirt/go-ovirt-client
https://github.com/oVirt/go-ovirt-client
-
github.com/ovirt/go-ovirt-client-log
https://github.com/oVirt/go-ovirt-client-log
These modules share the issue of depending on the hosting service
and the repo the code is located.
I started to work on the imageio go module here:
https://gerrit.ovirt.org/c/ovirt-imageio/+/117277
And I'm trying to avoid the issues above by naming the module:
ovirt.org/imageio
The module name does not depend on the hosting service, or on the
actual repo or the location in the repo.
To make this work, the web server at
ovirt.org should serve this resource:
https://ovirt.org/imageio
returning an HTML document that contains a magic <meta> tag in
the page header
<meta name="go-import"
content="ovirt.org/imageio git
https://github.com/ovirt/ovirt-imageio/imageio-go"/>
I found that this does not work, Go tools do not support a module not
in the root directory of a git repo.
We have several options to solve this:
1. Create new git repo for the Go imageio library
2. Publish the library using "github.com/ovirt/ovirt-imageio/imageio-go"
3. Serve the module from our web server (e.g.
resources.ovirt.org) using
the go proxy protocol.
I don't like option 1 since adding more tiny repos makes it harder to work with
the code and test it. We already have too many repos.
I don't like option 2 since this import path is horrible, and I don't want to
tie the project to github.
Option 3 is easy to implement - for every release you create a zip file
with the module, and few metadata files, and upload them to a web
server pointerd by the "go-import" meta tag.
We have the same problem with libnbd Go binding, and option 3 is likely
the right solution for it for similar reasons.
I want to get your input on this.
Nir