Proposal/Discussion: How to manage v3/swagger (and maybe other v3/* packages)

[VAveryanov8]

As far as I understand v3/* contains go modules (and packages) that can be used not only by Scylla Manager, but by some other projects (siren?).

Current integration with Scylla Manager is done as with any regular external dependency - entry in go.mod that points to repository url.

Advantages:

1. SM can use different version of v3/* packages (Do we need it?)

Disadvantages:

• If you need to change something in v3/* package and use your changes right away in SM, then it's required to complete two steps in general. Here is an example: imaging you need to use new api from scylla db, then
  1. Copy swagger definitions from Scylla to Scylla Manager repo, generate client and propagate changes to master branch
  2. In order to use latest changes it's required to update go.mod with latest version of v3/swaggerfrom master branch
• Updating v3/* dependency may force automatic update of other transitive dependencies (minimal version selection)

What we can do differently:

use replace directive in go.mod pointing to a local version of v3/* packages, e.g.

...
replace (
    github.com/scylladb/scylla-manager/v3/swagger => ./v3/swagger
)
...

Then SM is always using local(latest) version of v3/swagger, but other projects are relying on versioning of SM.

What do you think? Maybe I'm mussing some context here

P.S. Similar method is used in kubernetes project: https://github.com/kubernetes/kubernetes/blob/6b031e50b2abfe15434beef6c7e01056091a26ea/go.mod#L225 https://github.com/kubernetes/kubernetes/tree/master/staging#external-repository-staging-area

[Michal-Leszczynski]

As far as I understand v3/* contains go modules (and packages) that can be used not only by Scylla Manager, but by some other projects (siren?).

Correct - although I believe that we only care for the managerclient module to be exposed. Note that managerclient is importing the swagger module as well. @karol-kokoszka could you describe why we have separate swagger and utils modules?

SM can use different version of v3/* packages (Do we need it?)

We don't.

Similar method is used in kubernetes project:

I see that they are also using the go workspaces alongside manual replace directives - I don't really know why - I will try to learn a little bit more about that.

But in general I agree that working on cross module changes is really annoying - right now I'm using local go workspaces, but it would be nicer to have a solution that's integrated with the repository.