Re: [go-nuts] Interaction between Modules and GOPATH
On 4/17/19 2:50 PM, andrey mirtchovski wrote: If you are fetching it with "go get" then that's presumably because it's a dependency required by another package or module, in which case the go command will use the correct place for it based on whether "go get" was run inside a module directory (then it goes in the module cache) or anywhere else (then it goes into GOPATH). If you are not fetching the project as part of a dependency, because you want to work on it, modify it, etc, then you can clone it anywhere outside GOPATH on your system and don't need to use "go get". One of the use cases for go modules was to allow projects to reside everywhere on the filesystem to allow legacy directory layouts to be used when developing. So do *not* use go get when manually cloning the project then I take it? -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Canonical module arrangement in a multi-language project.
I am working on setting up NTPsec's build system to properly handle Go code, and can only find limited information of the preferred way of structuring the directory tree. Forcing the entire project into GOPATH would be sloppy and a giant kluge all around. Placing the go code in a folder with no special structure (as we currently do with Python), and then using relative module paths appears to work in testing. However from what I gather relative module paths are a deeply unkosher feature that should not be depended on. The only other way I see is simply to replicate a GOPATH directory structure within the project and have the build tools define a custom GOPATH. This forces a somewhat clunky directory structure on the project with an otherwise unneeded src/ directory. A possible workaround would be to structure the code as with Python, then have the build system copy the files into a src/ directory under build/ and run with that GOPATH. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
