go modules and internal packages

[R Srinivasan]

I have so far not migrated towards the new go modules. I am beginning the process. Looking for ideas.

I split my applications into indepe

[R Srinivasan]

Oops. That was messed up.

I have so far not migrated towards the new go modules. I am beginning the process. Looking for ideas.

I split my applications into independent packages each in its own directory.

the structure might look like:

top/src

         /pkg1

         /pkg2

the imports are based on relative paths - eg:

import (

    "../pkg1"

)

Questions:

- there is just 1 go.mod at the top level right?

- go.mod only specifies what the external packages are. eg.google.olang.org/package

this appears a bit counter to the go module setup.

what are the recommendations regarding internal packages. 

appreciate pointers.

thanks, srini

[t hepudds]

Hello Srini,

There is a decent answer covering some points on how to structure your module, options on where to place your go.mod file, and how to arrange your packages within a module here:

https://stackoverflow.com/a/57314494

One thing to note is that it says in that answer that you cannot use relative import paths like `import "../pkg2"` or `import "./subpkg"` when using modules.

You seem to be using relative import paths in your example, which is not going to work.

You should instead import a package within your module using the full import path of that package, which starts with the module name, such as `import "github.com/me/mymod/pkg1"`

Finally, if you haven’t already, I highly recommend reading the official “How to Write Go Code” document, which has recently been updated to cover modules:

https://golang.org/doc/code.html

And of course, please don’t hesitate to post any follow-up questions here, or in a new thread.

Best,
thepudds

[Lutz Horn]

Take a look at these blog articles:

https://blog.golang.org/using-go-modules
https://blog.golang.org/migrating-to-go-modules

Lutz

________________________________________
Von: golan...@googlegroups.com <golan...@googlegroups.com> im Auftrag von R Srinivasan <s...@srin.me>
Gesendet: Dienstag, 28. Januar 2020 00:29
An: golang-nuts
Betreff: [go-nuts] go modules and internal packages

I have so far not migrated towards the new go modules. I am beginning the process. Looking for ideas.

I split my applications into indepe

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com<mailto:golang-nuts...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fea9c93a-bb07-4f90-adcf-ebc5f6c71ae5%40googlegroups.com<https://groups.google.com/d/msgid/golang-nuts/fea9c93a-bb07-4f90-adcf-ebc5f6c71ae5%40googlegroups.com?utm_medium=email&utm_source=footer>.

[R Srinivasan]

Thanks a bunch.

Based on these, I should be including the repo name in my imports - even for private packages. If the repo changes, then the code has to be edited. For example I use an in-house instance of say bitbucket and then publish to the world on GitHub ,the sources will have to change to point to the new repo (for the internal packages)

Am I reading these wrong?

srini

On Tuesday, January 28, 2020 at 2:36:14 AM UTC-5, Lutz Horn wrote:

Take a look at these blog articles:

https://blog.golang.org/using-go-modules
https://blog.golang.org/migrating-to-go-modules

Lutz

________________________________________
Von: golan...@googlegroups.com <golan...@googlegroups.com> im Auftrag von R Srinivasan <s...@srin.me>
Gesendet: Dienstag, 28. Januar 2020 00:29
An: golang-nuts
Betreff: [go-nuts] go modules and internal packages

I have so far not migrated towards the new go modules. I am beginning the process. Looking for ideas.

I split my applications into indepe

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com<mailto:golang-nuts+unsubscribe@googlegroups.com>.

[Manlio Perillo]

On Tuesday, January 28, 2020 at 12:34:04 AM UTC+1, R Srinivasan wrote:

Oops. That was messed up.

I have so far not migrated towards the new go modules. I am beginning the process. Looking for ideas.

I split my applications into independent packages each in its own directory.

the structure might look like:

top/src

         /pkg1

         /pkg2

the imports are based on relative paths - eg:

import (

    "../pkg1"

)

That's really the wrong way to go.

If top is equal to $GOPATH, then there is no need to use relative imports.

If you do `import "pkg1", the import path will be automatically resolved to top/src/pkg1.

The difference with the new modules systems is that import paths will no longer be resolved to a local filesystem path using $GOPATH.

 

Questions:

- there is just 1 go.mod at the top level right?

- go.mod only specifies what the external packages are. eg.google.olang.org/package

I'm a bit confused to what do you mean as top level.

Assuming pkg1 and pkg2 are different projects, maybe inside a vcs repository, then each project will have it's own go.mod file.

If the projects are inside GOPATH (yes, GOPATH is still useful with modules), run `go mod init` inside the project root directory, and it will automatically create a new go.mod file.

Also, with modules *all* packages not inside a module are external.

This means that the module path should specify a remove resource, like "github.com/user/project".

If the module path is like "pkg1", go will report an error since it does not know how to get it.

The alternative is to use the replace directive.  You can check the official documentation or the wiki.

Manlio Perillo