Put River CLI into its own submodule #107
Merged
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.
Background: While trying to figure out how to safely release [1]
(which includes a new
riverdriver
submodule), I threw myself through aloop and realized that it'd be practically impossible to do without a
whole bunch of manual finnagling on the release tags/lint settings in
the repo, or breaking the master build, or most likely, both.
This got me thinking: maybe we should, maybe we should be using
replace
directives to make this less painful/brittle, which wereoriginally removed in #35 because using
replace
makes it impossible touse
go install ...@latest
.A change that we made recently was the addition of a new Go migration
API in #65 (
rivermigrate
), and a side effect of that change is thatthe API being used by the River CLI became entirely public (previously,
it'd depended on packages in River's
internal
). By extension, thatmeans it's now possible to make the River CLI its own Go module,
something that was infeasible before because of the use of
internal
.So my thinking currently: maybe we should go back to trying to see if we
can make
replace
in use by most of River's core packages, and keep theRiver CLI as its own module without
replace
so that it can still beinstalled with
go install ...@latest
. I'm not entirely sure we won'trun into another problem, but it might be the easiest thing in the
meantime. As the River CLI expands, we'll need to make sure to only use
public APIs, but that might not be the worst thing anyway -- we could
adopt the philosophy that any function the CLI accesses should also be
accessible by the Go API.
Here, notably we still use a
replace
, which I'm finding that I need tohave a passing build for now, and which I think will have to temporarily
stay until we cut a new release. Trying to build the new submodule
without results in this error that I was unable to otherwise find a way
around:
[1] #98