You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I run go get with an exact version, I usually want exactly that version.
If the go command decides that it can't arrive at the dependency for some reason,
then I believe that it should fail with an error and leave the dependencies unchanged
rather than silently choosing a different version.
For example, if I want to downgrade a module version, I want to know if the downgrade cannot be done.
I've included an example below of a case where the Go command silently chooses a different
resolved version from the requested version. This does not happen if go get -m
is used, but this silent success is confusing. A better result would be for the go get command to fail with an error that the package is not available at the
requested version. To reproduce, save to a file and run github.com/rogpeppe/go-internal/cmd/testscript
on it.
This is related to #29268 but more general.
When I run
go get
with an exact version, I usually want exactly that version.If the go command decides that it can't arrive at the dependency for some reason,
then I believe that it should fail with an error and leave the dependencies unchanged
rather than silently choosing a different version.
For example, if I want to downgrade a module version, I want to know if the downgrade cannot be done.
I've included an example below of a case where the Go command silently chooses a different
resolved version from the requested version. This does not happen if
go get -m
is used, but this silent success is confusing. A better result would be for the
go get
command to fail with an error that the package is not available at therequested version. To reproduce, save to a file and run
github.com/rogpeppe/go-internal/cmd/testscript
on it.
The text was updated successfully, but these errors were encountered: