Using the replace verb in go modules for labix.org mgo












0















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 files go.mod and go.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
...
)









share|improve this question





























    0















    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 files go.mod and go.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
    ...
    )









    share|improve this question



























      0












      0








      0








      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 files go.mod and go.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
      ...
      )









      share|improve this question
















      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 files go.mod and go.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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 16 '18 at 6:25







      Sonia Hamilton

















      asked Nov 16 '18 at 5:42









      Sonia HamiltonSonia Hamilton

      1,78022339




      1,78022339
























          2 Answers
          2






          active

          oldest

          votes


















          0














          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?






          share|improve this answer
























          • 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





















          0














          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





          share|improve this answer


























          • 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












          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          0














          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?






          share|improve this answer
























          • 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


















          0














          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?






          share|improve this answer
























          • 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
















          0












          0








          0







          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?






          share|improve this answer













          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?







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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





















          • 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















          0














          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





          share|improve this answer


























          • 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
















          0














          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





          share|improve this answer


























          • 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














          0












          0








          0







          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





          share|improve this answer















          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






          share|improve this answer














          share|improve this answer



          share|improve this answer








          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



















          • 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Florida Star v. B. J. F.

          Danny Elfman

          Lugert, Oklahoma