Working on a Terraform Provider for Teleport as a separate go module in gravitational/teleport-plugins, I've noticed the following:
go get github.com/gravitational/teleport, it installs v4.3.8 +incompatible. auth.Client, I needed to use 5.0. Conventional go get github.com/gravitational/[email protected] doesn't work and complaints on an incorrect version. I'd assume that just [email protected] would work as it would just use the 5.0 branch. go get github.com/gravitational/teleport@master, it installs v1.3.3-0.20201201014150-c4583b7a1af6, which _is_ the latest version from master, but the version number seems weird. I'll add a link to my branch to reproduce this in a few hours.
Is this go module version number intentional, or is this a bug?
Related: when I use teleport as a dependency in a separate go module, I also have to add a few replace statements for my module to compile:
replace (
github.com/coreos/go-oidc => github.com/gravitational/go-oidc v0.0.3
github.com/iovisor/gobpf => github.com/gravitational/gobpf v0.0.1
github.com/sirupsen/logrus => github.com/gravitational/logrus v0.10.1-0.20171120195323-8ab1e1b91d5f
google.golang.org/grpc => google.golang.org/grpc v1.27.0
)
That's probably fine. If I don't replace oidc and gobpf, I just get build errors, and fixing dependency versions fixes that. FYI.
We don't define versions in the go.mod file currently which is why this is happening; we use git tags for Teleport versioning instead. Whether we should change/fix this is probably a separate discussion.
I think that these should work for your use case:
go get github.com/gravitational/teleport@branch/5.0go get github.com/gravitational/teleport@ac4971801fb9bd50ef215ed80c9e42016ede573c (the commit hash of the v5.0.0 tag)@xnutsive the weird version when you do go get github.com/gravitational/teleport@master is a side-effect of go modules design and their expectations around repo tags. It's fine, as long as the commit hash looks correct.
The teleport repo wasn't designed to be an importable library, which is why our tagging is weird and replace directives are necessary.
We could potentially update https://github.com/gravitational/teleport/blob/master/go.mod#L1 to something like github.com/gravitational/teleport/v5 to resolve the go get errors.
But it's more of a hack, since our versioning scheme isn't proper semver (e.g. we only promise compatibility between binary behavior, not library APIs).
The "correct" solution is https://github.com/gravitational/teleport/pull/4746 (cc @Joerger), where we would extract client libraries into a separate module that follows the proper module semantics and versioning. Plus, it will decrease the number of transient dependencies for you.
Thanks for clarification! Agreed on all points:
Most helpful comment
@xnutsive the weird version when you do
go get github.com/gravitational/teleport@masteris a side-effect of go modules design and their expectations around repo tags. It's fine, as long as the commit hash looks correct.The teleport repo wasn't designed to be an importable library, which is why our tagging is weird and
replacedirectives are necessary.We could potentially update https://github.com/gravitational/teleport/blob/master/go.mod#L1 to something like
github.com/gravitational/teleport/v5to resolve thego geterrors.But it's more of a hack, since our versioning scheme isn't proper semver (e.g. we only promise compatibility between binary behavior, not library APIs).
The "correct" solution is https://github.com/gravitational/teleport/pull/4746 (cc @Joerger), where we would extract client libraries into a separate module that follows the proper module semantics and versioning. Plus, it will decrease the number of transient dependencies for you.