container/golang: move google-cloud-go/tree/main/internal/librariangen

[julieqiu]

One of the things we decided on was that all of the containers would live in container/ and be written in Go.

Since google-cloud-go/tree/internal/librariangen is already written in Go, we should move it to container/golang (go is a special keyword in Go, so use golang instead of go for the package name).

librariangen is currently the module cloud.google.com/go/internal/postprocessor/librarian/librariangen. We should remove the go.mod file when moving to avoid having nested modules, and so that these codebases share the same dependency versions.

[julieqiu]

/cc @jskeet

[jskeet]

@julieqiu I've been thinking about this. There are various interacting changes to consider:

• Moving the code
• Potentially making a change to allow the container to work somewhat differently for different repos (initially go-genproto; I have a very rough and ready prototype which details how I'd probably want to refactor significantly
• Potentially refactoring as we move so that common code in the container was in a common place for other containers
• Possible further repo consolidation
• Any changes in Librarian 2.0

My personal gut feel is that I'd prefer to get a better sense of what the code will look like longer term before moving it out of google-cloud-go, but if you'd prefer to move first and then refactor in place, we can definitely do that. Having checked with @quartzmo it shouldn't be a lot of work. (There'll be toil of changing GCB triggers etc, but that's inevitable.)

I'll assign this to myself as I'll probably be the person to do it whenever we decide to, but would welcome feedback about timing.

[julieqiu]

If we just moved the code today, what do we expect will break? My assumption is that we can do all of those things just as easily from github.com/googleapis/librarian as we can from github.com/googleapis/google-cloud-go, and it would make it easier to refactor as we work on refactoring the CLI design.

[jskeet]

I don't think anything will break - I just wonder whether creating the container from scratch with a new design would be easier than refactoring in place. But that's a weakly held opinion, and I'm happy to just ignore it and migrate if you'd prefer that.

[ldetmer]

I think it makes sense to migrate the code as is to Librarian, so when we do start making changes for 2.0, Go migration to 2.0 will be easier. However I would NOT perform any refactoring at this time, as we are expecting to make changes to the language container contract as part of the next Librarian iteration.

[jskeet]

Righto. I'll aim to get that done this week. (Of course, we'll then find some reason why it's more complicated than I expected, but...)