Using the replace verb in go modules for labix.org mgo
Using go modules, I would like to replace labix.org/v2/mgo
with github.com/globalsign/mgo
. The http://labix.org/mgo repository is unmaintained and has been forked to https://github.com/globalsign/mgo
- my code is stored outside
$GOPATH
in the directory~/git/foo
- I'm using go1.11
- other go modules are working (for example
go list -m all
lists other modules, the filesgo.mod
andgo.sum
are updating automatically. See the full file below)
I've tried the following in the go.mod
file:
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
Running go build
gives the following error:
build github.com/foo/bar: cannot find module for path labix.org/v2/mgo
The documentation in go help modules
discusses Pseudo-Versions eg v0.0.0-yyy..
, which I'm trying to use because the tags on https://github.com/globalsign/mgo are of the form r2018.06.15
and not v1.2.3
(semantic versioning).
In addition go help modules
says:
Pseudo-versions never need to be typed by hand: the go command will accept
the plain commit hash and translate it into a pseudo-version (or a tagged
version if available) automatically. This conversion is an example of a
module query.
However I can't work out the command for generating a pseudo-version when I'm in the cloned github.com/globalsign/mgo
(located at $GOPATH/src/github.com/globalsign/mgo
). Hence the pseudo-version I've manually generated may be wrong.
The full go.mod
file looks like:
module github.com/foo/bar
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
require (
github.com/DATA-DOG/godog v0.7.8
github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721 // indirect
github.com/alecthomas/repr v0.0.0-20181024024818-d37bc2a10ba1 // indirect
...
)
go
add a comment |
Using go modules, I would like to replace labix.org/v2/mgo
with github.com/globalsign/mgo
. The http://labix.org/mgo repository is unmaintained and has been forked to https://github.com/globalsign/mgo
- my code is stored outside
$GOPATH
in the directory~/git/foo
- I'm using go1.11
- other go modules are working (for example
go list -m all
lists other modules, the filesgo.mod
andgo.sum
are updating automatically. See the full file below)
I've tried the following in the go.mod
file:
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
Running go build
gives the following error:
build github.com/foo/bar: cannot find module for path labix.org/v2/mgo
The documentation in go help modules
discusses Pseudo-Versions eg v0.0.0-yyy..
, which I'm trying to use because the tags on https://github.com/globalsign/mgo are of the form r2018.06.15
and not v1.2.3
(semantic versioning).
In addition go help modules
says:
Pseudo-versions never need to be typed by hand: the go command will accept
the plain commit hash and translate it into a pseudo-version (or a tagged
version if available) automatically. This conversion is an example of a
module query.
However I can't work out the command for generating a pseudo-version when I'm in the cloned github.com/globalsign/mgo
(located at $GOPATH/src/github.com/globalsign/mgo
). Hence the pseudo-version I've manually generated may be wrong.
The full go.mod
file looks like:
module github.com/foo/bar
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
require (
github.com/DATA-DOG/godog v0.7.8
github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721 // indirect
github.com/alecthomas/repr v0.0.0-20181024024818-d37bc2a10ba1 // indirect
...
)
go
add a comment |
Using go modules, I would like to replace labix.org/v2/mgo
with github.com/globalsign/mgo
. The http://labix.org/mgo repository is unmaintained and has been forked to https://github.com/globalsign/mgo
- my code is stored outside
$GOPATH
in the directory~/git/foo
- I'm using go1.11
- other go modules are working (for example
go list -m all
lists other modules, the filesgo.mod
andgo.sum
are updating automatically. See the full file below)
I've tried the following in the go.mod
file:
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
Running go build
gives the following error:
build github.com/foo/bar: cannot find module for path labix.org/v2/mgo
The documentation in go help modules
discusses Pseudo-Versions eg v0.0.0-yyy..
, which I'm trying to use because the tags on https://github.com/globalsign/mgo are of the form r2018.06.15
and not v1.2.3
(semantic versioning).
In addition go help modules
says:
Pseudo-versions never need to be typed by hand: the go command will accept
the plain commit hash and translate it into a pseudo-version (or a tagged
version if available) automatically. This conversion is an example of a
module query.
However I can't work out the command for generating a pseudo-version when I'm in the cloned github.com/globalsign/mgo
(located at $GOPATH/src/github.com/globalsign/mgo
). Hence the pseudo-version I've manually generated may be wrong.
The full go.mod
file looks like:
module github.com/foo/bar
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
require (
github.com/DATA-DOG/godog v0.7.8
github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721 // indirect
github.com/alecthomas/repr v0.0.0-20181024024818-d37bc2a10ba1 // indirect
...
)
go
Using go modules, I would like to replace labix.org/v2/mgo
with github.com/globalsign/mgo
. The http://labix.org/mgo repository is unmaintained and has been forked to https://github.com/globalsign/mgo
- my code is stored outside
$GOPATH
in the directory~/git/foo
- I'm using go1.11
- other go modules are working (for example
go list -m all
lists other modules, the filesgo.mod
andgo.sum
are updating automatically. See the full file below)
I've tried the following in the go.mod
file:
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
Running go build
gives the following error:
build github.com/foo/bar: cannot find module for path labix.org/v2/mgo
The documentation in go help modules
discusses Pseudo-Versions eg v0.0.0-yyy..
, which I'm trying to use because the tags on https://github.com/globalsign/mgo are of the form r2018.06.15
and not v1.2.3
(semantic versioning).
In addition go help modules
says:
Pseudo-versions never need to be typed by hand: the go command will accept
the plain commit hash and translate it into a pseudo-version (or a tagged
version if available) automatically. This conversion is an example of a
module query.
However I can't work out the command for generating a pseudo-version when I'm in the cloned github.com/globalsign/mgo
(located at $GOPATH/src/github.com/globalsign/mgo
). Hence the pseudo-version I've manually generated may be wrong.
The full go.mod
file looks like:
module github.com/foo/bar
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
require (
github.com/DATA-DOG/godog v0.7.8
github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721 // indirect
github.com/alecthomas/repr v0.0.0-20181024024818-d37bc2a10ba1 // indirect
...
)
go
go
edited Nov 16 '18 at 6:25
Sonia Hamilton
asked Nov 16 '18 at 5:42
Sonia HamiltonSonia Hamilton
1,78022339
1,78022339
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
When using the replace
directive, leave the pseudo-version out.
It's also stated here, which points to an open issue.
Probably off-topic, but I've mostly used replace
when I wanted to use a local version of some dependency. Why not import
the forked lib which you'd like to use (instead of the original non-maintained one) and have mod resolve it properly?
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
add a comment |
The source being replaced (in this case labix.org/v2/mgo
) also needs to be added to the require list with a version of v0.0.0
(even though it won't be downloaded). In the replace the source doesn't need a version but the target does.
However I haven't worked out how to auto-generate the pseudo version for the target (github.com/globalsign/mgo
in this case), so I still needed to manually generate it.
Here's a better go.mod file:
1 module foo.bar/qux
2
3 replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
4
5 require (
6 github.com/DATA-DOG/godog v0.7.8
7 github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
<snip>
21 golang.org/x/image v0.0.0-20181116024801-cd38e8056d9b // indirect
22 labix.org/v2/mgo v0.0.0
23 )
Notice the require of labix.org
on line 22; go mod tidy
accepts this.
However I now come up against a different issue, the use of internal packages (referred to in issues like this: https://github.com/golang/go/issues/23970). I still haven't solved this new problem.
% go build main.go
/home/sonia/go/pkg/mod/github.com/globalsign/mgo@v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df/auth.go:38:2:
use of internal package github.com/globalsign/mgo/internal/scram not allowed
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53332079%2fusing-the-replace-verb-in-go-modules-for-labix-org-mgo%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
When using the replace
directive, leave the pseudo-version out.
It's also stated here, which points to an open issue.
Probably off-topic, but I've mostly used replace
when I wanted to use a local version of some dependency. Why not import
the forked lib which you'd like to use (instead of the original non-maintained one) and have mod resolve it properly?
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
add a comment |
When using the replace
directive, leave the pseudo-version out.
It's also stated here, which points to an open issue.
Probably off-topic, but I've mostly used replace
when I wanted to use a local version of some dependency. Why not import
the forked lib which you'd like to use (instead of the original non-maintained one) and have mod resolve it properly?
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
add a comment |
When using the replace
directive, leave the pseudo-version out.
It's also stated here, which points to an open issue.
Probably off-topic, but I've mostly used replace
when I wanted to use a local version of some dependency. Why not import
the forked lib which you'd like to use (instead of the original non-maintained one) and have mod resolve it properly?
When using the replace
directive, leave the pseudo-version out.
It's also stated here, which points to an open issue.
Probably off-topic, but I've mostly used replace
when I wanted to use a local version of some dependency. Why not import
the forked lib which you'd like to use (instead of the original non-maintained one) and have mod resolve it properly?
answered Nov 16 '18 at 10:02
HavelockHavelock
5,91732639
5,91732639
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
add a comment |
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
Thanks @havelock, I'll check this out during the week. From memory, omitting version information gives errors. Also, rather than rewriting import everywhere (using sed) I actually want to practice this feature of mod -- substituting one library for another. In this particular case it's not a big deal, but in future I could see it being so - eg in a large automated build chain.
– Sonia Hamilton
Nov 17 '18 at 20:36
add a comment |
The source being replaced (in this case labix.org/v2/mgo
) also needs to be added to the require list with a version of v0.0.0
(even though it won't be downloaded). In the replace the source doesn't need a version but the target does.
However I haven't worked out how to auto-generate the pseudo version for the target (github.com/globalsign/mgo
in this case), so I still needed to manually generate it.
Here's a better go.mod file:
1 module foo.bar/qux
2
3 replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
4
5 require (
6 github.com/DATA-DOG/godog v0.7.8
7 github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
<snip>
21 golang.org/x/image v0.0.0-20181116024801-cd38e8056d9b // indirect
22 labix.org/v2/mgo v0.0.0
23 )
Notice the require of labix.org
on line 22; go mod tidy
accepts this.
However I now come up against a different issue, the use of internal packages (referred to in issues like this: https://github.com/golang/go/issues/23970). I still haven't solved this new problem.
% go build main.go
/home/sonia/go/pkg/mod/github.com/globalsign/mgo@v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df/auth.go:38:2:
use of internal package github.com/globalsign/mgo/internal/scram not allowed
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
add a comment |
The source being replaced (in this case labix.org/v2/mgo
) also needs to be added to the require list with a version of v0.0.0
(even though it won't be downloaded). In the replace the source doesn't need a version but the target does.
However I haven't worked out how to auto-generate the pseudo version for the target (github.com/globalsign/mgo
in this case), so I still needed to manually generate it.
Here's a better go.mod file:
1 module foo.bar/qux
2
3 replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
4
5 require (
6 github.com/DATA-DOG/godog v0.7.8
7 github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
<snip>
21 golang.org/x/image v0.0.0-20181116024801-cd38e8056d9b // indirect
22 labix.org/v2/mgo v0.0.0
23 )
Notice the require of labix.org
on line 22; go mod tidy
accepts this.
However I now come up against a different issue, the use of internal packages (referred to in issues like this: https://github.com/golang/go/issues/23970). I still haven't solved this new problem.
% go build main.go
/home/sonia/go/pkg/mod/github.com/globalsign/mgo@v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df/auth.go:38:2:
use of internal package github.com/globalsign/mgo/internal/scram not allowed
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
add a comment |
The source being replaced (in this case labix.org/v2/mgo
) also needs to be added to the require list with a version of v0.0.0
(even though it won't be downloaded). In the replace the source doesn't need a version but the target does.
However I haven't worked out how to auto-generate the pseudo version for the target (github.com/globalsign/mgo
in this case), so I still needed to manually generate it.
Here's a better go.mod file:
1 module foo.bar/qux
2
3 replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
4
5 require (
6 github.com/DATA-DOG/godog v0.7.8
7 github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
<snip>
21 golang.org/x/image v0.0.0-20181116024801-cd38e8056d9b // indirect
22 labix.org/v2/mgo v0.0.0
23 )
Notice the require of labix.org
on line 22; go mod tidy
accepts this.
However I now come up against a different issue, the use of internal packages (referred to in issues like this: https://github.com/golang/go/issues/23970). I still haven't solved this new problem.
% go build main.go
/home/sonia/go/pkg/mod/github.com/globalsign/mgo@v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df/auth.go:38:2:
use of internal package github.com/globalsign/mgo/internal/scram not allowed
The source being replaced (in this case labix.org/v2/mgo
) also needs to be added to the require list with a version of v0.0.0
(even though it won't be downloaded). In the replace the source doesn't need a version but the target does.
However I haven't worked out how to auto-generate the pseudo version for the target (github.com/globalsign/mgo
in this case), so I still needed to manually generate it.
Here's a better go.mod file:
1 module foo.bar/qux
2
3 replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
4
5 require (
6 github.com/DATA-DOG/godog v0.7.8
7 github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
<snip>
21 golang.org/x/image v0.0.0-20181116024801-cd38e8056d9b // indirect
22 labix.org/v2/mgo v0.0.0
23 )
Notice the require of labix.org
on line 22; go mod tidy
accepts this.
However I now come up against a different issue, the use of internal packages (referred to in issues like this: https://github.com/golang/go/issues/23970). I still haven't solved this new problem.
% go build main.go
/home/sonia/go/pkg/mod/github.com/globalsign/mgo@v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df/auth.go:38:2:
use of internal package github.com/globalsign/mgo/internal/scram not allowed
edited Nov 19 '18 at 1:33
answered Nov 19 '18 at 1:12
Sonia HamiltonSonia Hamilton
1,78022339
1,78022339
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
add a comment |
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
did you solve the issue with internal package? i'm having the same issue
– tristan
Feb 19 at 6:25
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
Trying to remember, I'm on holidays... 2 things I found useful: 1) to auto-generate the pseudo version number for packages, setup a dummy Go project that requires the package in a .go file, then after 'go mod tidy' the version number appears in go.mod for copy/paste 2) the internal packages issue - this was caused by the 'sub' package not following semantic versioning. If you get the 'parent' package working using previous 'go mod tidy' will auto pickup children; otherwise manually generate the version numbers using the previous trick, then write 'replaces' for all the sub packages :-(
– Sonia Hamilton
Feb 20 at 1:01
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53332079%2fusing-the-replace-verb-in-go-modules-for-labix-org-mgo%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown