Cockroach: build: migrate to go modules

[lopezator]

Now that https://github.com/cockroachdb/cockroach/issues/34919 https://github.com/cockroachdb/cockroach/issues/33709 and https://github.com/cockroachdb/apd/issues/83 got merged, it will be technically possible to replace dep in favor of modules, so that tools vendorizing cockroachdb/cockroachdb-gen (and using modules), could do this seemlessly.

I got it working in:

https://github.com/lopezator/sqlfmt/blob/master/go.mod

By forking cockroach-gen, and adding:

https://github.com/lopezator/cockroach/blob/master/go.mod

But it's an ugly hack that could be avoided if cockroach && cockroach-gen switches to go modules.

[knz]

Thanks for your report! IT's a bit late to do this in the 19.1 release cycle, but we'll seriously consider this for 19.2 (the next one).

[akshayjshah]

I'd also love this - I'm trying to use github.com/cockroach/cockroachdb/pkg/sql/parser to test that my migrations are idempotent, but it's difficult to install using modules.

[lopezator]

Now that modules is considered stable on 1.14 maybe it's time to reactivate this.

[AndreySerebrovC2M]

Can I help to migrate to go modules?

[knz]

You can certainly help! Just be aware that it's likely a relatively complex task.

[AndreySerebrovC2M]

You can certainly help! Just be aware that it's likely a relatively complex task.

I want to. But I don't fill the power to lead this process)

[knz]

FYI the entire crdb team is currently busy with the upcoming 20.1 release and we won't be leading this either for a month or two.

[AndreySerebrovC2M]

FYI the entire crdb team is currently busy with the upcoming 20.1 release and we won't be leading this either for a month or two.

Ok! I'm ready to take part in this process

[IliaRusin]

I'd love to help you with this task!

[alexander-manley]

CRDB version 20.1 has been released. Adding go.mod and go.sum files to the root of the repository would be a good initial step. Google senior engineer Jean de Klerk, has authored a starting reference on how to approach the move to the official/standard approach to modularizing an existing codebase: https://blog.golang.org/migrating-to-go-modules

[knz]

At this time there is still a lot of work to be done due to the following:

• a lot of code is auto-generated, with complex, relatively deep build pipelines that are incompatible with "go generate". It might be possible to work around this by mirroring the tree into a separate tree with only generated files, for example this: http://github.com/cockroachdb/cockroach-gen

• a number of vendored dependencies are currently incompatible with go modules. These will need to be selectively upgraded, and the code in cockroachdb adapted to use their new APIs (and tested).

[otan]