-
-
Notifications
You must be signed in to change notification settings - Fork 196
Packr in a subdirectory of a module #169
Comments
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.
|
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). |
Worth noting, that when the module is outside GOPATH |
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.
|
Yeah, that's why I asked, whether this is a limitation or a bug.
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?
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 It might be a separate issue, but the |
Modules use the main projects module name as an indicator of sub modules so they don't have to be specified separately. To fix this use the module name from mod.go then append "/packrd". |
I think the way I would characterize this bug is that packr2 does not follow the same spec for finding Can packr2 maybe consult the GOMOD environmental variable to see whether modules are in use, and which |
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.
|
To future users: if you are hitting this edge-case, upgrade to >= 1.12 and the fix will work. |
I've hit this use case as well, but upgrading didn't fix it. Still, I get
// Edit |
I use go modules in a project and when trying to generate packr in a subpackage of module, I get the following generated file:
(this is from circle)
The subpackage I executed
packr2
in isinternal/cli/command/form
, and it's outside of the GOPATH. When executingpackr2
withGO111MODULE=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?The text was updated successfully, but these errors were encountered: