16

I'm trying to import from Jenkins-X/jx to customize some stuff a little bit.

I'm really new to go heads up

but trying to go get ./... fails.

my go.mod file

module github.com/my-org/my-project

go 1.13

require github.com/jenkins-x/jx v2.0.383

I get

... require github.com/jenkins-x/jx: version "v2.0.383" invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

which is because jx has a few requirements in its mod file

But I'm not sure what I have to do to actually download the module.

Benbentwo
  • 391
  • 1
  • 2
  • 10
  • 4
    https://github.com/golang/go/wiki/Modules#semantic-import-versioning – JimB Sep 23 '19 at 16:31
  • 4
    Yeah, it looks like they've totally broken that repo for importing as a library (though it doesn't appear to be intended for import as a library). As the page Jim linked shows, a major version change necessitates a path change (i.e. for v2.x the path should be github.com/jenkins-x/jx/v2). – Adrian Sep 23 '19 at 16:39
  • to add to what has been said, it seems like you want to do some hacking on `jenkins-x`. If that's the case, I'd recommend cloning that repo, making changes to it, and building your own custom binary from source. The [jenkins-x contribution guidelines](https://jenkins-x.io/contribute/development/) should help you with that – Robbie Milejczak Sep 23 '19 at 16:46
  • The problem is I was hoping to make a web server calling jx functions directly, I've written it in bash / python hybrid but it seems hacky to have a container with jx installed to run the cobra commands rather than just call the functions directly, so I was hoping to rewrite it in go. – Benbentwo Sep 23 '19 at 16:51

1 Answers1

2

In go a major version bump must ensure that the import path is different from other major version. The v1 version doesn't need any suffix, all following major version bump must have the major version suffix in the module name. In your case that should be:

require github.com/jenkins-x/jx/v2 v2.0.383

The import path used then in your go source files should also specify that. You can have more information about this convention here https://github.com/golang/go/wiki/Modules#why-must-major-version-numbers-appear-in-import-paths

But some module authors don't follow this rule and this is incompatible with what is expected from the go tool. If you have write access to the module, you should fix the module name so that the major version appears in the module definition.

For this specific package none of the major versions add the required suffix on the module name. I guess as it is a CLI tool, it is not supposed to be consumed by other modules. Anyway if you need to import that, you have a workaround by specifiying the commit id corresponding to the label you want to depend on:

go get github.com/jenkins-x/jx@c71c08508888ec

But you can expect to have other problem then because this module doesn't seem to expect to be consumed from other module.

And you will be also on your own to upgrade this package, the go tool won't be able to bump the version itself as it doesn't know the current one.

davidriod
  • 937
  • 5
  • 14