[
https://issues.apache.org/jira/browse/THRIFT-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248345#comment-17248345
]
Fedor Korotkiy commented on THRIFT-4685:
----------------------------------------
In my case, "git.apache.org/thrift.git/lib/go/thrift" and
"github.com/apache/thrift/lib/go/thrift" coexist just fine. I ended up solving
my conflict by patching import paths in vendored parquet-go, pointing it at my
fork of thrift. But that solution is not the best, because each repository must
duplicate that work. And it requires user of -mod=vendor build mode, which is
not always the case. The problem is not in my code, that is important. Conflict
is between two dependencies, that I have little control over.
thrift module is clean and small, without external dependencies, so I don't see
how multiple version might conflict.
> The real solution really should be for those third party libraries to update
> their thrift dependency. [0.9.3 is 5 year old
> now|https://github.com/apache/thrift/releases/tag/0.9.3]. tchannel-go says
> they don't want to do breaking changes in v1, that's fine and a valid point.
> But "don't want to bump to v2 in order to update a 5 year old dependency"
> really is not.
That would solve current problem, for sure. Now imagine that another
incompatible change is made to thrift/go.
1) If import paths are not versioned: All consumers should update at the same
time. Even single core library that lags behind (like tchannel-go), causes
problems for everyone downstream.
2) If import paths are versioned: There is clear path for update, that does not
require coordination. Cases, where I need to accept thrift message from one
library and pass it to another still break. But they are rare, compared to
cases where thrift is used internally (like jaeger-tracing and parquet).
By versioning import paths you are opening more upgrade options for downstream
projects.
> in reality consider thrift's unique case of compiler get mixed in.
Mixing compiler complicates things. But all go libraries commit generated code
to repository. Because of that, you only need to think about compiler version
for current module, and compiler version used by dependencies is irrelevant
(only generated code compatibility is important).
Here is an interesting example of a breaking change done recently
[https://blog.golang.org/protobuf-apiv2]
Recent protobuf update was made with upgrade plan in mind. Because of this, we
were able to update protobuf in out internal monorepo with relative ease.
> Support the new golang modules (1.11 or later)
> ----------------------------------------------
>
> Key: THRIFT-4685
> URL: https://issues.apache.org/jira/browse/THRIFT-4685
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Affects Versions: 0.12.0
> Environment: golang 1.11 or later
> Reporter: James E. King III
> Assignee: Duru Can Celasun
> Priority: Minor
>
> Go added new module support in 1.11, see:
> https://github.com/golang/go/wiki/Modules
> We should move towards it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
