[
https://issues.apache.org/jira/browse/BEAM-5379?focusedWorklogId=230214&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-230214
]
ASF GitHub Bot logged work on BEAM-5379:
----------------------------------------
Author: ASF GitHub Bot
Created on: 19/Apr/19 18:04
Start Date: 19/Apr/19 18:04
Worklog Time Spent: 10m
Work Description: lostluck commented on issue #8354: [BEAM-5379] Go
Modules versioning support
URL: https://github.com/apache/beam/pull/8354#issuecomment-484973209
If it were this simple I'd have done it already. :) I too hoped it was this
simple, but here are at least 2 problems with just adding the go.mod and go.sum
files:
These are totally up for discussion BTW, I'm willing to be convinced
whichever way, these are just the conclusions I came to when I thought it
through.
1. Beam testing (all those lovely precommit/post commit tests) uses Gradle
to manage these tasks. To do so with go we use GoGradle We need to remove the
gogradle lock file which it uses to manage it's only vendored versions of
things, and validate that GoGradle works with Go Modules, and outside of a
GOPATH. Otherwise we're defeating the prime benefit of GoModules, which is
hermetic reproducible builds, and we'd be testing the SDK under different
conditions/and dependencies than users would receive them.
* Two dependency files (effectively) would mean there's additional hoops to
add dependencies rather than just running the go tools. We'd also need to run
the gradle tools. This impedes adding useful dependencies, and contributions
from other Go users.
* This is the part that needs validation, and is why I haven't simply done
it yet, as it requires time to handle.
* For example I don't know if GoGradle operates properly outside of a
GoPath.
2. Putting these here makes the claim that the SDK is v2.X, when it should
be a v0.X.
* I do not want folks to mistakenly assume the SDK is production ready. Due
to the IOs, it's not.
* There are some parts that should be v2.X, since they're not part of the
SDK, just things written in Go, like the container boot code, or they should be
clients of the SDK. I posit the integration & regression tests, and the
examples should be outside of the user package, and depend on a clear version
of the user package. See
* Fortunately this divide is clear at sdks/go/pkg/beam , so we can put a
modules at sdks/go (as you've done), and at sdks/go/pkg/beam.
* Then it's a matter of using git tags with a sub path prefix
(sdks/go/pkg/beam/v0.X)
* And validating that things continue to work.
See
https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories for
clearer instructions and examples.
Now, while they're inter-related issues, we could probably do 2 separate
from 1, as long as we don't live in that mixed state for too long.
See
https://docs.google.com/document/d/1ZjP30zNLWTu_WzkWbgY8F_ZXlA_OWAobAD9PuohJxPg/edit#heading=h.drpipq762xi7
for some lengthy thoughts on they whys for most of this.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 230214)
Time Spent: 1h 10m (was: 1h)
> Go Modules versioning support
> -----------------------------
>
> Key: BEAM-5379
> URL: https://issues.apache.org/jira/browse/BEAM-5379
> Project: Beam
> Issue Type: Improvement
> Components: sdk-go
> Reporter: Robert Burke
> Assignee: Robert Burke
> Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This would make it easier for non-Go developers to update and test changes to
> the Go SDK without jumping through hoops to set up Go Paths at first.
> Right now, we us the gogradle plugin for gradle to handle re-producible
> builds. Without doing something with the GO_PATH relative to a user's local
> git repo though, changes made in the user's repo are not represented when
> gradle is invoked to test everything.
> One of at least the following needs to be accomplished:
> * gogradle moves to support the Go Modules experiment in Go 1.11, and the SDK
> migrates to that
> * or we re-implement our gradle go rules ourselves to use them,
> * or some third option, that moves away from the GO_PATH nit.
> This issue should be resolved after deciding and implementing a clear
> versioning story for the SDK, ideally along Go best practices.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
