Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Put River CLI into its own submodule #107

Merged
merged 1 commit into from
Dec 13, 2023
Merged

Conversation

brandur
Copy link
Contributor

@brandur brandur commented Dec 13, 2023

Background: While trying to figure out how to safely release [1]
(which includes a new riverdriver submodule), I threw myself through a
loop 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 were
originally removed in #35 because using replace makes it impossible to
use 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 that
the API being used by the River CLI became entirely public (previously,
it'd depended on packages in River's internal). By extension, that
means 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 the
River CLI as its own module without replace so that it can still be
installed with go install ...@latest. I'm not entirely sure we won't
run 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 to
have 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:

$ go test .
ambiguous import: found package github.com/riverqueue/river/cmd/river in multiple modules:
        github.com/riverqueue/river v0.0.12 (/Users/brandur/Documents/go/pkg/mod/github.com/riverqueue/[email protected]/cmd/river)
        github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river)

[1] #98

@brandur
Copy link
Contributor Author

brandur commented Dec 13, 2023

This one is the same as #102.

@brandur brandur force-pushed the brandur-modularize-cmd-river branch 2 times, most recently from 6b4a89d to 223a6d7 Compare December 13, 2023 02:27
Background: While trying to figure out how to safely release [1]
(which includes a new `riverdriver` submodule), I threw myself through a
loop 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 were
originally removed in #35 because using `replace` makes it impossible to
use `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 that
the API being used by the River CLI became entirely public (previously,
it'd depended on packages in River's `internal`). By extension, that
means 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 the
River CLI as its own module without `replace` so that it can still be
installed with `go install ...@latest`. I'm not entirely sure we won't
run 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 to
have 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:

    $ go test .
    ambiguous import: found package github.com/riverqueue/river/cmd/river in multiple modules:
            github.com/riverqueue/river v0.0.12 (/Users/brandur/Documents/go/pkg/mod/github.com/riverqueue/[email protected]/cmd/river)
            github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river)

[1] #98
@brandur
Copy link
Contributor Author

brandur commented Dec 13, 2023

Thanks!

@brandur brandur merged commit 477ece3 into master Dec 13, 2023
7 checks passed
@brandur brandur deleted the brandur-modularize-cmd-river branch December 13, 2023 02:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants