Commit Graph

5 Commits

Author SHA1 Message Date
Joe Tsai
41ef85a559 all: add weak dependency on github.com/golang/protobuf
Add back the weak dependency on github.com/golang/protobuf.

Change-Id: I2e6fabbe2cac3b694fb56a86bb3aa85cc8615b42
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/262684
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Damien Neil <dneil@google.com>
2021-03-18 00:24:57 +00:00
Joe Tsai
b7197c14de all: remove weak dependency on github.com/golang/protobuf
Temporarily remove the dependency on github.com/golang/protobuf
and add it back in a subsequent CL. This allows us to break some of
the infinite cycles of old versions in the go.sum file.

Change-Id: Ifb5c2c160713d47a43ba2bcedc18ebe2ce33dcea
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/262683
Trust: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Damien Neil <dneil@google.com>
2021-03-17 21:55:02 +00:00
Joe Tsai
9712361eda all: rely on dynamic dependency check for genproto
The genproto module incurs an unfortunate amount of dependency bloat
since it has a relatively large set of transitive dependencies.
Even though these are brought in as a weak dependency
(i.e., there is no hard code dependency on genproto),
it complicates dependency inspection since users need to vet
modules that they may not actually be using.

Avoid this weak dependency and instead rely on a dynamic check
to ensure that a sufficiently new version of genproto is used.
While it can't statically prevent old versions of genproto from being
linked into a binary, it guarantees that it will panic at init
with a helpful message on what's wrong.

Change-Id: I2b5a9759a5cd4c4c57aced54278502b1b6352ba7
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/262679
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
2020-10-15 21:46:17 +00:00
Joe Tsai
0567a55b47 all: add weak dependency on google.golang.org/genproto module
This is step 4 of 6 in a multi-stage migration
to move the well-known types
from the google.golang.org/genproto module
to the google.golang.org/protobuf module.

The generated Go packages for field_mask.proto, api.proto,
type.proto, and source_context.proto are being moved over
to this module alongside all the other well-known types.

In order to move these types between two modules,
there needs to be a sequence of changes submitted in
decently rapid succession. It is impossible to atomically
make these changes, so a brief breakage is inevitable.
The steps are as follows:

Step 1: Submit a change to cloud.google.com/go/internal/gapicgen
to avoid generating the well-known types. Otherwise, the tool
will undo the changes made in step 3.
See https://code-review.googlesource.com/c/gocloud/+/56810

Step 2: Submit a change to google.golang.org/protobuf that
adds the generated well-known types being migrated to that module.
In order to prevent the situation where a user links in
too old a version of the genproto module such that
duplicate registration occurs for the well-known types,
the registry is specially modified to provide an error
message that instructs users to upgrade the genproto module.
See https://golang.org/cl/234937

Step 3: Submit a change to google.golang.org/genproto that
switches all generated well-known types to be aliases to the
ones declared in google.golang.org/protobuf from the previous step.
This will cause the genproto module to incur an dependency
on an unreleased version of the protobuf module.
See https://github.com/googleapis/go-genproto/pull/372

Step 4: Submit a change to google.golang.org/protobuf that
adds a weak module depdency on the genproto module at the
revision from the previous step.
See https://golang.org/cl/235297

Step 5: Release google.golang.org/protobuf@v1.24.0.
See https://golang.org/cl/235299

Step 6: Submit a change to google.golang.org/genproto that
updates the protobuf module dependency to v1.24.0.

Change-Id: I22d496e7496446becad742eab05b169abb735ae2
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/235297
Reviewed-by: Damien Neil <dneil@google.com>
2020-05-26 22:06:12 +00:00
Damien Neil
06e51b76b4 internal/weakdeps: put APIv1 weak dependency behind a build constraint
By using a build constraint that is never satisfied, we can add a weak
dependency on a module. If the module is part of a build, our go.mod
enforces a minimum version on it, but we never add it to the build
dependencies ourselves.

This is the same trick used for tool dependencies:
https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

Dropped the TODO to remove the APIv1 dependency, since I think this
removes any need to do so.

Change-Id: I45b1a3f45535bcdc9abf34fb562d2869f1712bb6
Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/219499
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2020-02-14 21:08:34 +00:00