4 ms·

It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the pro

It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to set a different GOPATH per project, and then checkout the project deep into that root. This is not convenient as a developer and as a software packager. Or give in and having to resolve dependencies that work with all the current projects. Given that Go doesn't really do package versioning, finding the right set of commits that all work together is a exponential nightmare. Now that since Go 1.6 each project can have its own vendor/ folder, GOPATH shouldn't be required. I should be able to checkout the project where I want and then have the tools look into the vendor/ folder to resolve any dependencies. Please change it that way. The reason govendor and all these tools are complicated is because of this GOPATH madness. Synching dependencies between GOPATH and vendor/ should only be a problem for Google, not the rest of us.

rubenv 8y ago
It's a blessing when you want to start a new project while offline (e.g. on a plane or train). All your usual dependencies are already there, ready to use. Not that it justifies any pain, just found it to be a pleasant side-effect. Sometimes it's worthwhile to just give in and try something new, even if you don't like it. You might discover unexpected advantages. Then go back to what you prefer and apply those lessons there. Everything would be much better if we all kept an open mind and learned from each-others experiences. It might not always be obvious, but things are usually a certain way for a good reason. Might not be the best or right reason in the long run, but there's always some lesson to be learned.
- Can_Not 8y ago
  You could have a global cache folder instead of a global vendor folder.
  - MehdiHK 8y ago
    Exactly. Both yarn and npm cli support this for nodejs.
send_computers 8y ago
This seems like a description of NPM in the node ecosystem, they are incrementally solving all these issues.
- rco8786 8y ago
  That’s, like, the opposite of npm though. It does dependencies per project, versioning, and does not impose any filesystem restrictions. Not that it doesn’t have issues.
  - Can_Not 8y ago
    How is it the opposite of npm?
    - rco8786 8y ago
      All of the reasons I listed...?
      - Can_Not 8y ago
        But npm does all of those...
        rco8786 8y ago
        I know...Golang does the opposite of each of those. Here's some excerpts of the comment we responded to: > It's distasteful of Go to impose a filesystem layout. > To achieve [self-contained dependenceis] with Go, one has to set a different GOPATH per project, and then checkout the project deep into that root. > Given that Go doesn't really do package versioning...
ngrilly 8y ago
Work is ongoing to solve this: https://github.com/golang/vgo/ https://github.com/golang/vgo/. GOPATH won't be necessary anymore.
strkek 8y ago
I made[1] a zsh hook some time ago that allowed you to have per-project GOPATH. At the root of the project I just have to do `echo 'github.com/username/package' > .gopkg` and after that, for everything I do under that directory tree, GOPATH will be automatically set to something like `export GOPATH="$(dirname .gopkg)/.gopath"`. I don't use zsh anymore though. [1]: https://gist.github.com/strkek/294c2f5e6fe94b8303b5121266b27a22 https://gist.github.com/strkek/294c2f5e6fe94b8303b5121266b27...
- zimbatm 8y ago
  nice, you could do something similar using direnv[1] [1]: https://direnv.net/ https://direnv.net/
heavenlyhash 8y ago
Try this: https://github.com/warpfork/gof https://github.com/warpfork/gof It's pretty easy to declare a GOPATH that's local to your project. I've been quietly doing it for years. The linked repo is just one short shell script that helps do it (on any project; you don't even have to commit the script, and it doesn't change how anyone else develops). Frankly, I think every highly-productive gopher outside the Google offices uses some form or another of this. It's unpopular to say it and goes against "the community" zeitgeist, but many people will admit it in private if you ask around. My biggest complaint about the current state of Go dependency management is actually the vendor dir. We never needed it; project-local GOPATH is enough in the first place. Now, we just get the headaches when both exist and are in conflict, or one provides something that should've been in the other (not a problem, until you push, and someone else on the team has to tell you that you didn't vendor enough...)

rubenv 8y ago

It's a blessing when you want to start a new project while offline (e.g. on a plane or train). All your usual dependencies are already there, ready to use. Not that it justifies any pain, just found it to be a pleasant side-effect. Sometimes it's worthwhile to just give in and try something new, even if you don't like it. You might discover unexpected advantages. Then go back to what you prefer and apply those lessons there. Everything would be much better if we all kept an open mind and learned from each-others experiences. It might not always be obvious, but things are usually a certain way for a good reason. Might not be the best or right reason in the long run, but there's always some lesson to be learned.

Can_Not 8y ago
You could have a global cache folder instead of a global vendor folder.
- MehdiHK 8y ago
  Exactly. Both yarn and npm cli support this for nodejs.

send_computers 8y ago

This seems like a description of NPM in the node ecosystem, they are incrementally solving all these issues.

rco8786 8y ago
That’s, like, the opposite of npm though. It does dependencies per project, versioning, and does not impose any filesystem restrictions. Not that it doesn’t have issues.
- Can_Not 8y ago
  How is it the opposite of npm?
  - rco8786 8y ago
    All of the reasons I listed...?
    - Can_Not 8y ago
      But npm does all of those...
      - rco8786 8y ago
        I know...Golang does the opposite of each of those. Here's some excerpts of the comment we responded to: > It's distasteful of Go to impose a filesystem layout. > To achieve [self-contained dependenceis] with Go, one has to set a different GOPATH per project, and then checkout the project deep into that root. > Given that Go doesn't really do package versioning...

ngrilly 8y ago

Work is ongoing to solve this: https://github.com/golang/vgo/ https://github.com/golang/vgo/. GOPATH won't be necessary anymore.

strkek 8y ago

I made[1] a zsh hook some time ago that allowed you to have per-project GOPATH. At the root of the project I just have to do `echo 'github.com/username/package' > .gopkg` and after that, for everything I do under that directory tree, GOPATH will be automatically set to something like `export GOPATH="$(dirname .gopkg)/.gopath"`. I don't use zsh anymore though. [1]: https://gist.github.com/strkek/294c2f5e6fe94b8303b5121266b27a22 https://gist.github.com/strkek/294c2f5e6fe94b8303b5121266b27...

zimbatm 8y ago
nice, you could do something similar using direnv[1] [1]: https://direnv.net/ https://direnv.net/

heavenlyhash 8y ago

Try this: https://github.com/warpfork/gof https://github.com/warpfork/gof It's pretty easy to declare a GOPATH that's local to your project. I've been quietly doing it for years. The linked repo is just one short shell script that helps do it (on any project; you don't even have to commit the script, and it doesn't change how anyone else develops). Frankly, I think every highly-productive gopher outside the Google offices uses some form or another of this. It's unpopular to say it and goes against "the community" zeitgeist, but many people will admit it in private if you ask around. My biggest complaint about the current state of Go dependency management is actually the vendor dir. We never needed it; project-local GOPATH is enough in the first place. Now, we just get the headaches when both exist and are in conflict, or one provides something that should've been in the other (not a problem, until you push, and someone else on the team has to tell you that you didn't vendor enough...)