Rename Go module from github.com/vmware-tanzu/antrea to antrea.io/antrea #2166
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
BTW, I have already configured the antrea.io website to serve the HTML data required for the vanity import path to work. |
Codecov Report
@@ Coverage Diff @@
## main #2166 +/- ##
==========================================
+ Coverage 61.07% 65.28% +4.21%
==========================================
Files 270 270
Lines 20486 20486
==========================================
+ Hits 12512 13375 +863
+ Misses 6672 5745 -927
- Partials 1302 1366 +64
Flags with carried forward coverage won't be shown. Click here to find out more.
|
This is a pretty straightforward change with one exception: we cannot use the default Protobuf package names for Antrea APIs because of name resolution in protoc and because of how go-to-protobuf references messages defined in other .proto files. go-to-protobuf will not add a leading dot to the message path, and in that case protoc does resolution starting from the inbermost scope. Default package names start with "antrea.io.antrea." which means that for any message reference that matches "antrea.io.antrea.<path>", protoc will look for "antrea.io.antrea.io.antrea.<path>" which obviously will fail. To avoid a "sed" hack to add a leading dot (which would require us to run protoc directly), we rename the package names to "antrea_io.antrea.*". Even though this causes some extra code to be re-generated, there shouldn't be any impact at all on backwards-compatibility: the Protobuf messages themselves do not change. Consumers of the Antrea Go module should update the import path they use for Antrea. If these consumers are "pinning" a version of Antrea which is on a release branch that was created before the repository transfer (for now, all release branches...), their code should keep working. See antrea-io#2154
antoninbas
force-pushed
the
rename-go-module-to-antrea.io/antrea
branch
from
1d6a315
to
628aa96
Compare
|
/test-all |
1 similar comment
|
/test-all |
jianjuns
approved these changes
May 12, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a pretty straightforward change with one exception: we cannot
use the default Protobuf package names for Antrea APIs because of name
resolution in protoc and because of how go-to-protobuf references
messages defined in other .proto files. go-to-protobuf will not add a
leading dot to the message path, and in that case protoc does resolution
starting from the inbermost scope. Default package names start with
"antrea.io.antrea." which means that for any message reference that
matches "antrea.io.antrea.", protoc will look for
"antrea.io.antrea.io.antrea." which obviously will fail. To avoid
a "sed" hack to add a leading dot (which would require us to run protoc
directly), we rename the package names to "antrea_io.antrea.*". Even
though this causes some extra code to be re-generated, there shouldn't
be any impact at all on backwards-compatibility: the Protobuf messages
themselves do not change.
Consumers of the Antrea Go module should update the import path they use
for Antrea. If these consumers are "pinning" a version of Antrea which
is on a release branch that was created before the repository transfer
(for now, all release branches...), their code should keep working.
See #2154