How to use "internal" packages?

Go

Go Problem Overview


I try understand how to organize go code using "internal" packages. Let me show what the structure I have:

project/
  internal/
    foo/
      foo.go # package foo
    bar/
      bar.go # package bar
  main.go

# here is the code from main.go
package main

import (
  "project/internal/foo"
  "project/internal/bar"
)

project/ is outside from GOPATH tree. Whatever path I try to import from main.go nothing works, the only case working fine is import "./internal/foo|bar". I think I do something wrong or get "internal" package idea wrong in general. Could anybody make things clearer, please?

UPDATE

The example above is correct the only what I need was to place project/ folder under $GOPATH/src. So the thing is import path like the project/internal/foo|bar is workable if we only import it from project/ subtree and not from the outside.

Go Solutions


Solution 1 - Go

With modules introduction in Go v1.11 and above you don't have to specify your project path in $GOPATH/src

You need to tell Go about where each module located by creating go.mod file. Please refer to go help mod documentation.

Here is an example of how to do it:

project
|   go.mod
|   main.go
|
\---internal
    +---bar
    |       bar.go
    |       go.mod
    |
    \---foo
            foo.go
            go.mod

project/internal/bar/go.mod

module bar

go 1.14

project/internal/bar/bar.go

package bar

import "fmt"

//Bar prints "Hello from Bar"
func Bar() {
	fmt.Println("Hello from Bar")
}

project/internal/foo/go.mod

module foo

go 1.14

project/internal/foo/foo.go

package foo

import "fmt"

//Foo prints "Hello from Foo"
func Foo() {
	fmt.Println("Hello from Foo")
}

project/main.go

package main

import (
	"internal/bar"
	"internal/foo"
)

func main() {
	bar.Bar()
	foo.Foo()
}

Now the most important module project/go.mod

module project

go 1.14


require internal/bar v1.0.0
replace internal/bar => ./internal/bar
require internal/foo v1.0.0
replace internal/foo => ./internal/foo

Couple things here:

  1. You can have any name in require. You can have project/internal/bar if you wish. What Go think it is URL address for the package, so it will try to pull it from web and give you error
go: internal/bar@v1.0.0: malformed module path "internal/bar": missing dot in first path element

That is the reason why you need to have replace where you tell Go where to find it, and that is the key!

replace internal/bar => ./internal/bar
  1. The version doesn't matter in this case. You can have v0.0.0 and it will work.

Now, when you execute your code you will have

Hello from Bar
Hello from Foo

Here is GitHub link for this code example

Solution 2 - Go

The packages have to be located in your $GOPATH in order to be imported. The example you gave with import "./internal/foo|bar" works because it does a local-import. internal only makes it so code that doesn't share a common root directory to your internal directory can't import the packages within internal.

If you put all this in your gopath then tried to import from a different location like OuterFolder/project2/main.go where OuterFolder contains both project and project2 then import "../../project/internal/foo" would fail. It would also fail as import "foo" or any other way your tried due to not satisfying this condition;

> An import of a path containing the element “internal” is disallowed if > the importing code is outside the tree rooted at the parent of the > “internal” directory.

Now if you had the path $GOPATH/src/project then you could do import "foo" and import "bar" from within $GOPATH/src/project/main.go and the import would succeed. Things that are not contained underneath project however would not be able to import foo or bar.

Solution 3 - Go

below way is more scalable, especially when you plan to build multiple binaries

github.com/servi-io/api
├── cmd/
│   ├── servi/
│   │   ├── cmdupdate/
│   │   ├── cmdquery/
│   │   └── main.go
│   └── servid/
│       ├── routes/
│       │   └── handlers/
│       ├── tests/
│       └── main.go
├── internal/
│   ├── attachments/
│   ├── locations/
│   ├── orders/
│   │   ├── customers/
│   │   ├── items/
│   │   ├── tags/
│   │   └── orders.go
│   ├── registrations/
│   └── platform/
│       ├── crypto/
│       ├── mongo/
│       └── json/

The folders inside cmd/ represents the number of binaries you want to build.

for more

Solution 4 - Go

Also to check: When you are using your externally imported object types: make sure you are prefixing them with the namespace they're in. As a golang newbie, I didn't know I had to do that, and was wondering why is VS Code just removing my import (for not being used) when I saved. It's because I had to prefix the imported object with the namespace name:

Example:
import (
    "myInternalPackageName"  // works fine as long as you follow all instructions in this thread
)

//Usage in code: 
myInternalPackageName.TheStructName   // prefix it, or it won't work. 

If you don't put the namespace prefix before the object/struct name, VS code just removes your import for being unused, and then you still have the error: "Can't find TheStructName"... That was very confusing, and I had to do a build without VS code through the command line to understand that.

The point is: I had to specify the package prefix when actually using the struct from that internal package.

If you don't want to use the qualifier prefix when using imported objects, use:

import . "thePath"    // Can use contents without prefixing. 

Reference: https://stackoverflow.com/questions/6478962/what-does-the-dot-or-period-in-a-go-import-statement-do

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionTimur FayzrakhmanovView Question on Stackoverflow
Solution 1 - GoVlad BezdenView Answer on Stackoverflow
Solution 2 - GoevanmcdonnalView Answer on Stackoverflow
Solution 3 - GoEdwin O.View Answer on Stackoverflow
Solution 4 - GoFranticRockView Answer on Stackoverflow