
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"/> Is this possible with our current infrastructure? Should we rename all the go modules to fit this scheme? Nir

On Wed, Oct 27, 2021 at 6:19 PM Nir Soffer <nsoffer@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:
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"/>
Is this possible with our current infrastructure?
If that's all you want, I guess you should simply open an infra ticket, no?
Should we rename all the go modules to fit this scheme?
Perhaps do something slightly different: Use a subdir, or a subdomain, such as go.ovirt.org/imageio or ovirt.org/go/imageio, and ask for this place to be managed using a git repo somewhere (in gerrit or elsewhere), so that when you merge there stuff, something updates the namespace automatically. This way you do not need to ping infra per each project. Best regards, -- Didi

On Wed, Oct 27, 2021 at 10:03 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Wed, Oct 27, 2021 at 6:19 PM Nir Soffer <nsoffer@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:
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"/>
Is this possible with our current infrastructure?
If that's all you want, I guess you should simply open an infra ticket, no?
I want to discuss the issue and possible solutions
Should we rename all the go modules to fit this scheme?
Perhaps do something slightly different: Use a subdir, or a subdomain, such as go.ovirt.org/imageio or ovirt.org/go/imageio, and ask for this place to be managed using a git repo somewhere (in gerrit or elsewhere), so that when you merge there stuff, something updates the namespace automatically. This way you do not need to ping infra per each project.
This is nicer since using "ovirt.org/name" for a go module prevents using this name for something else. But hopefully we can do this using the current ovirt site infrastructure, for example adding a wiki page with a special metadata key, or syntax that will generate the <meta> tag like: --- title: oVirt ... Go module meta: name=... content=... --- Page text... This way the same page can also contain useful content about the resource. Nir

On Wed, Oct 27, 2021 at 6:18 PM Nir Soffer <nsoffer@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:
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

On Sat, Nov 6, 2021 at 1:53 AM Nir Soffer <nsoffer@redhat.com> wrote:
To make this work, the web server at ovirt.org should serve this resource:
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.
I forgot to include the relevant issue: https://github.com/golang/go/issues/34055
participants (2)
-
Nir Soffer
-
Yedidyah Bar David