Do not use import "forjj/subpackage" in go code

[clarsonneur]

Forjj has subpackage like creds. And forjj GO files uses "forjj/creds" to import it and run it.

glides and go work fines with that setup, but go get do not work at all when we try to import this repo to godoc.

The go get command cannot install this package because of the following issues:

Unrecognized import path "forjj/repo" (app.go:10:2)
Unrecognized import path "forjj/creds" (update.go:5:2)
Unrecognized import path "forjj/scandrivers" (secrets_edit.go:5:2)
Unrecognized import path "forjj/drivers" (driver.go:6:2)
Unrecognized import path "forjj/forjfile" (driver.go:7:2)
Unrecognized import path "forjj/utils" (driver.go:9:2)
Unrecognized import path "forjj/git" (driver.go:8:2)
Unrecognized import path "forjj/flow" (app.go:8:2)

Following glide documentation, subpackage exist for the main project, but as they used in glide code, they set the full path. ie: (example: https://github.com/Masterminds/glide/blob/master/glide.go)

import "github.com/Masterminds/glide/path"

So, it is not clear that we should not set it as:

import "glide/path"
but as
import "github.com/Masterminds/glide/path"

The first format is nice for 2 reasons:

• path is shorter
• glide and go won't refer to a copy of forjj in vendor.

The 2nd reason was important when you develop both, the main and the submodule.
When you use the long path, glide will add forjj in the vendor directory, which is based on the latest commit. So, any pending code not commited are not pushed to the vendor directory.

Means that when you want to build your code, you must run git commit and glide, to build it...
Which is too expensive.

May be the approach on glide would be to develop the sub module, test it (unit testing) and deliver it in commit, so that we can develop the usage of that sub module change from the main.

In short, decorelate the sub package development and the main package development.

I will change the development, to match this and help using godoc (and go get)