Packr in a subdirectory of a module

[sagikazarmark]

I use go modules in a project and when trying to generate packr in a subpackage of module, I get the following generated file:

// +build !skippackr
// Code generated by github.com/gobuffalo/packr/v2. DO NOT EDIT.

// You can use the "packr clean" command to clean up this,
// and any other packr generated files.
package form

import _ "home/circleci/project/internal/cli/command/form/packrd"

(this is from circle)

The subpackage I executed packr2 in is internal/cli/command/form, and it's outside of the GOPATH. When executing packr2 with GO111MODULE=on it stops with an error:

Error: go.mod cannot be read or does not exist while go module is enabled.

Is it a bug or a limitation that packr2 can only be executed in the root module?

[markbates]

It probably has more to do with modules than Packr. Does the problem persist if you don’t use modules? If it does it’s packr, if not, than its modules.

…

----------- Mark Bates

On Feb 27, 2019, 4:02 PM -0500, Márk Sági-Kazár ***@***.***>, wrote: I use go modules in a project and when trying to generate packr in a subpackage of module, I get the following generated file: // +build !skippackr // Code generated by github.com/gobuffalo/packr/v2. DO NOT EDIT. // You can use the "packr clean" command to clean up this, // and any other packr generated files. package form import _ "home/circleci/project/internal/cli/command/form/packrd" (this is from circle) The subpackage I executed packr2 in is internal/cli/command/form, and it's outside of the GOPATH. When executing packr2 with GO111MODULE=on it stops with an error: Error: go.mod cannot be read or does not exist while go module is enabled. Is it a bug or a limitation that packr2 can only be executed in the root module? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sagikazarmark]

Well, this is an interesting situation, because if go modules is off, the package has to be inside GOPATH, which makes the package name kinda obvious.

If I explicitly turn go modules off and move the package away from GOPATH, the issue still persists, but this is somewhat expected (although throwing an error might be better in this case).

[sagikazarmark]

Worth noting, that when the module is outside GOPATH GO111MODULE=on makes packr fail (with the error above), GO111MODULE=auto works as described above.

[markbates]

I’m not sure I can help you. All I can say is: * Even with modules you should ALWAYS work in your GOPATH * When you run packr it uses either go.mod or the GOPATH to build the imports. If neither of those are present where you run the tool, things aren’t going to come out correctly.

…

----------- Mark Bates

On Feb 27, 2019, 4:19 PM -0500, Márk Sági-Kazár ***@***.***>, wrote: Worth noting, that when the module is outside GOPATH GO111MODULE=on makes packr fail (with the error above), GO111MODULE=auto works as described above. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[sagikazarmark]

Yeah, that's why I asked, whether this is a limitation or a bug.

• Even with modules you should ALWAYS work in your GOPATH

Not sure I understand the reason behind. A huge selling point of go modules is that you are not limited to the GOPATH anymore. Also, with the transition period (which actually ended this week with Go 1.12) the default behavior of Go suggested that go modules should NOT be in the GOPATH.

Is this a personal preference of yours or a recommendation for packr?

When you run packr it uses either go.mod or the GOPATH to build the imports.

Well, there is a go.mod file in the module, although packr is executed in a subdirectory. Since the Go tool works inside a subdirectory, I guess it goes up in the directory tree to find a go.mod file. Is that something that would make sense for packr?

It might be a separate issue, but the GO111MODULE=on vs GO111MODULE=auto also seems to be strange. Maybe auto is not considered by packr.

[orxobo]

Modules use the main projects module name as an indicator of sub modules so they don't have to be specified separately.
ie. if you project has a module name of "mycompany/mycoolproject" any sub module under that has to be imported as "mycompany/mycoolproject/mysubmodule", and in the case of packrd it should be "mycompany/mycoolproject/packrd" not the whole path.

To fix this use the module name from mod.go then append "/packrd".
so the fixed import line in main-packr.go would look like:
import _ "mycompany/mycoolproject/packrd"

[Jarema]

@orxobo The whole path problem and need for such workaround occurs only of you don't have explicit usage of modules turned on with GO111MODULE=on. Though if you have it only #175 happens to occur for me (if main package is not in root)

[kat-co]

I think the way I would characterize this bug is that packr2 does not follow the same spec for finding go.mod files as the Go toolchain does. Go pops up directories until it finds a go.mod.

Can packr2 maybe consult the GOMOD environmental variable to see whether modules are in use, and which go.mod to use? It seems like a good way to piggy-back off the hard work the toolchain is laready doing.

[markbates]

PRs welcome

…

----------- Mark Bates

On Mar 19, 2019, 11:35 AM -0400, Katherine Cox-Buday ***@***.***>, wrote: I think the way I would characterize this bug is that packr2 does not follow the same spec for finding go.mod files as the Go toolchain does. Go pops up directories until it finds a go.mod. Can packr2 maybe consult the GOMOD environmental variable to see whether modules are in use, and which go.mod to use? It seems like a good way to piggy-back off the hard work the toolchain is laready doing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[kat-co]

To future users: if you are hitting this edge-case, upgrade to >= 1.12 and the fix will work.

[JamesCullum]

I've hit this use case as well, but upgrading didn't fix it.

Still, I get

...
�[37mDEBU�[0m[2019-05-10T09:59:28+02:00] found 1 boxes
�[37mDEBU�[0m[2019-05-10T09:59:28+02:00] *store.Disk#Pack �[37mbox�[0m=assets
�[37mDEBU�[0m[2019-05-10T09:59:28+02:00] *store.Disk#Close
Error: go.mod cannot be read or does not exist while go module is enabled.

// Edit
It is actually related to this issue: #171
I fixed it by moving the project to within GOPATH (normal Go works outside for non-libraries)