Comment out replace directive for riverpgxv5
#35
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
brandur
force-pushed
the
brandur-comment-out-replace
branch
from
eda7e2d to
6db5660
Compare
|
@bgentry I suppose the other thing we could do here is to also make I guess I don't really care that much as long as we have something that works. Do you want to play around with this a bit and see if you can find something that works? Feel free to push to https://github.com/bgentry/riverdemo/pull/7 to see if you can get that working. |
|
Doh, the |
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable. We have two variants: * Install within a Go Module. This is theoretically nice because it'd get the same version of the River CLI as the River you're using, but has a very large downside currently in that it requires you to add the CLI's dependencies to your stack before it works. e.g. Cobra. * Install outside a Go Module with the equivalent of `@latest` (uses the ref of the branch being built in CI). This is currently broken until a fix like #35 can come in. Long term, this job may become too much of a maintenance headache because Go has some really annoying caching behavior around modules, but I didn't experience that while writing it, so it might be worthwhile seeing whether this turns out to be valuable.
I was trying to get CI working for the River demo project [1] and found
that it's not currently possible to install the River CLI to another Go
project:
Run go install github.com/riverqueue/river/cmd/river@latest
go: downloading github.com/riverqueue/river v0.0.4
go: github.com/riverqueue/river/cmd/river@latest (in github.com/riverqueue/river@v0.0.4):
The go.mod file for the module providing named packages contains one or
more replace directives. It must not contain directives that would cause
it to be interpreted differently than if it were the main module.
Error: Process completed with exit code 1.
This is roughly consistent with what I'd previously understood for
`replace`. It's useful for debugging problems during development, but I
don't think it's meant to be a permanent decoration on a project. A
decent compromise is to keep it commented out, but available in case
it's needed to debug something, which is what I've done here.
Also, probably goes to show why it's important to keep a demo app
maintained so we can notice problems of this sort.
[1] riverqueue/riverdemo#7
brandur
force-pushed
the
brandur-comment-out-replace
branch
from
6db5660 to
7c4109d
Compare
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Pertaining to the problem described in #35, seems like a good idea to have a CI check make sure that nothing we've done with Go modules has made the CLI not installable. We have two variants: * Install within a Go Module. This is theoretically nice because it'd get the same version of the River CLI as the River you're using, but has a very large downside currently in that it requires you to add the CLI's dependencies to your stack before it works. e.g. Cobra. * Install outside a Go Module with the equivalent of `@latest` (uses the ref of the branch being built in CI). This is currently broken until a fix like #35 can come in. Long term, this job may become too much of a maintenance headache because Go has some really annoying caching behavior around modules, but I didn't experience that while writing it, so it might be worthwhile seeing whether this turns out to be valuable.
bgentry
approved these changes
Nov 19, 2023
Comment on lines
+26
to
+27
| github.com/riverqueue/river/riverdriver/riverpgxv5 v0.0.4 h1:336o1gbjpsSe1I9Es0eoJkBagXTmkXdzZ1M8j9kwLUU= | ||
| github.com/riverqueue/river/riverdriver/riverpgxv5 v0.0.4/go.mod h1:k6hsPkW9Fl3qURzyLHbvxUCqWDpit0WrZ3oEaKezD3E= |
There was a problem hiding this comment.
- What's the process for cutting a new release if we go this route?
- As part of cutting a new release, will the
go.modandgo.sumdisagree with each other around the required version ofriverpgxv5? - After shipping this change, if a user installs
river@latest, will they also get the latestriverpgxv5no matter what thisgo.sumsays?
If we need to be certain about any of this we can experiment w/ my other repo first.
There was a problem hiding this comment.
- What's the process for cutting a new release if we go this route?
I think either:
- Use the same release process as before and accept that the build is temporarily broken.
- Two phase release where river is tagged and after that's in, riverpgxv5 is tagged.
- As part of cutting a new release, will the
go.modandgo.sumdisagree with each other around the required version ofriverpgxv5?
I don't know.
- After shipping this change, if a user installs
river@latest, will they also get the latestriverpgxv5no matter what thisgo.sumsays?
I think the go.sum is only locking for the current module, but not 100% sure about this.
|
Doh, this is blocking me from getting another project online, so going to merge for now. I'll play around with the release process and update docs according to what I find. |
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Changelog for v0.0.5 in which we mention removing the `replace` directive as in #35.
brandur
added a commit
that referenced
this pull request
Nov 19, 2023
Changelog for v0.0.5 in which we mention removing the `replace` directive as in #35.
brandur
added a commit
that referenced
this pull request
Dec 9, 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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
Dec 9, 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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
Dec 9, 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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
Dec 9, 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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
brandur
added a commit
that referenced
this pull request
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/river@v0.0.12/cmd/river) github.com/riverqueue/river/cmd/river (/Users/brandur/Documents/projects/river/cmd/river) [1] #98
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I was trying to get CI working for the River demo project [1] and found
that it's not currently possible to install the River CLI to another Go
project:
This is roughly consistent with what I'd previously understood for
replace. It's useful for debugging problems during development, but Idon't think it's meant to be a permanent decoration on a project. A
decent compromise is to keep it commented out, but available in case
it's needed to debug something, which is what I've done here.
Also, probably goes to show why it's important to keep a demo app
maintained so we can notice problems of this sort.
[1] https://github.com/bgentry/riverdemo/pull/7