Teleport: go get github.com/gravitational/teleport@master gets version 1.3.3-{date}-{latest-commit-sha}. Is the version correct?

Created on 1 Dec 2020  ·  4Comments  ·  Source: gravitational/teleport

Working on a Terraform Provider for Teleport as a separate go module in gravitational/teleport-plugins, I've noticed the following:

  • When I just do go get github.com/gravitational/teleport, it installs v4.3.8 +incompatible.
  • Since the provider will rely on a bunch of new things in 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.
  • If I do 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?

Most helpful comment

@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.

All 4 comments

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.0
  • go 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:

  1. “It works”, and the version / tag semantics are not critically important for gravitational/teleport repo as it's not really intended to be imported.
  2. Extracting a client package would be nice. I guess I'll be one of the first consumers of that Client outside of Teleport core.
Was this page helpful?
0 / 5 - 0 ratings