[
https://issues.apache.org/jira/browse/BEAM-5379?focusedWorklogId=230383&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-230383
]
ASF GitHub Bot logged work on BEAM-5379:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Apr/19 06:09
Start Date: 20/Apr/19 06:09
Worklog Time Spent: 10m
Work Description: nfisher commented on issue #8354: [BEAM-5379] Go
Modules versioning support
URL: https://github.com/apache/beam/pull/8354#issuecomment-485061799
I'm assuming there's a tonne of context I lack! Hopefully this wall of text
yields a fruitful discussion through my naive questions and poking at the
boundary of required vs desired.
I gave a first reading through the Gdoc you referenced thanks for that. I
probably need another pass or two to ensure I grasp the nuance.
> If it were this simple I'd have done it already. :)
I assumed as much but was curious whether there was anything that prevented
build/test with the naivest/smallest change possible. I suppose I could've
equally discussed it in the issue but I sometimes find working code is easier
to identify and clarify concrete concerns and issues.
> Beam testing ... uses Gradle to manage these tasks.
> prime benefit of GoModules, which is hermetic reproducible builds
Is GoGradle a hard requirement or is it merely the desire and ability to
employ a common build tool? If an alternative reproducible build/test cycle
could be implemented by other means which still provided Gradle build targets,
precommit, etc would that be considered/tick the boxes? From a dependency graph
basis is Go modules not an adequate mechanism to yield a hermetic reproducible
build (e.g. go.sum pins detailed version info for the full dependency graph
including transitive deps)? Tangental but on the topic of hermetic builds
presumably Go tool-chain compatibility is a concern? I've seen a number of
libraries cite they will support the latest N minor versions of Go. Is there a
goal for Beam to do similar (e.g. support Go v{1.N & 1.N-1} currently {v1.11 &
v1.12})? Implies there's a build matrix required for version verification is
there one already and does that relax some of the binary reproducibility
aspects?
> makes the claim that the SDK is v2.X, when it should be a v0.X
Understanding that more broadly 0.X is a common idiom to indicate "there be
dragons" and "API changes are highly probable". If it's explicit in the SDK
documentation for Go does the version number *really* matter? Spinning it from
another angle could a v2.X tagging be a "compatible with/to" in the Beam graph
definition sense rather than a measure of maturity? As a further example, am I
correct in stating that the Python and Java libraries haven't always had
feature parity but have carried the same version at a given tag/commit?
As a user I think I would find a capability matrix a more informative
measure of utility than version at this stage in the project as versioning is
often subjective and somewhat arbitrary. Naively I feel in the Go community (or
at least within projects I've consumed) there's often "fluidity/fluctuation" in
API's even within minor versions.
> 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.
Probably an example where my lack of context/familiarity with the codebase
is failing me. Am I correct in understanding that `sdks/go` is the "private"
code and CLI executables and `pkg` is the public API where `sdks/go`,
`sdks/go/pkg/beam`, and user code will often be compiled into a single binary
executable? If yes, as a user I think it's fair to expect them to be the same
version. I did note that beamctl exists in the cmd folder so I assume there's
also client/server tooling to consider and perhaps that's the larger concern
you're outlining?
----------------------------------------------------------------
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: 230383)
Time Spent: 1.5h (was: 1h 20m)
> 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: 1.5h
> 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)
