Change imports path from weaveworks to fluxcd

[stefanprodan]

Change imports path from weaveworks to fluxcd and rename go module to github.com/fluxcd/flux.

[luxas]

Thanks @stefanprodan, this was the next step after #2304 to make it consumable from the outer world

[squaremo]

We need to be careful about when to make this change, since it will break builds that haven't vendored or pinned github.com/weaveworks/flux.

[luxas]

We need to be careful about when to make this change, since it will break builds that haven't vendored or pinned github.com/weaveworks/flux.

Can you expand on this? I do not understand what you mean with "haven't vendored or pinned"?

[squaremo]

We need to be careful about when to make this change, since it will break builds that haven't vendored or pinned github.com/weaveworks/flux.

Can you expand on this? I do not understand what you mean with "haven't vendored or pinned"?

When the module is renamed, it won't be addressable as github.com/weaveworks/flux any more.

By "vendored" I mean added the files from github.com/weaveworks/flux into your own source tree. If you've done that, you don't care if it disappears from elsewhere.

By "pinned" I mean specified a particular version in a lockfile or in go.mod. If you've done that, the go tooling might not bother trying to fetch the module.

So in those two circumstances, downstream builds might not break, at least not immediately.

However: my idea of go mod has mostly been formed percussively, so the above is only a halfway-informed guess.

[luxas]

When the module is renamed, it won't be addressable as github.com/weaveworks/flux any more.

Are you sure? I've seen github.com/docker/docker imports being automatically redirected to moby/moby when importing, so I think github helps us here.

By "vendored" I mean added the files from github.com/weaveworks/flux into your own source tree. If you've done that, you don't care if it disappears from elsewhere.

That's true. But at the moment you can't vendor fluxcd/flux in a new project, nor upgrade as it tries to find the old weaveworks module which doesn't exist (in the right place) anymore.

By "pinned" I mean specified a particular version in a lockfile or in go.mod. If you've done that, the go tooling might not bother trying to fetch the module.

Go modules automatically pin. So nobody's stuff should automatically break (I think).
When upgrading to a new version which is fluxcd, you (obviously) need to rename the import references to fluxcd, however.

TL;DR; In the current state, nobody can vendor fluxcd/flux. Vendoring weaveworks/flux works still. Pinning is done automatically by go.mod, so nobody's deps break automatically. We should go ahead and rename this to fluxcd/flux, and I believe both names will work.

[squaremo]

moby/moby doesn't use go mod (and therefore doesn't, for instance, assign itself a module name), so how it behaves is somewhat moot.

In any case: I don't believe there are many projects that depend on github.com/weaveworks/flux, and any that break outright are easily fixed.

So long as we are convinced that there are no end-user-observable differences after the module name change*, let's at least wait for 1.14.0 to be released, then give people a bit of warning via Slack and the mailing list.

*Are we convinced? My suspicions would lie with anywhere that drops type names into data, so:

• serialisation, e.g., to events; I don't think the package name matters there, but this has burned before
• RPC, similarly to serialisation
• any auto-generated code

[squaremo]

Looks good, on the basis that:

• all changes are to do with the module name change (and the vast majority are changes to imports, as I'd expect)
• grepping for weaveworks did not reveal any imports that haven't been updated and should have been
• it still builds