5 ms·

Honestly I got the impression no one ever liked gopath.

by cgag 8y ago

revskill 8y ago
Because setting environment variables is something most devs like to avoid.
- cgag 8y ago
  No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.
  - cyphar 8y ago
    I have tried several times to fix this problem in the past 5 or 6 years, once with symlinks (which would break quite often -- it's unsurprising that Plan 9 developers wouldn't care too much for handling symlinks correctly :P). The current way I handle it is that $HOME/.local is my GOPATH, and $HOME/src links to $HOME/.local/src. So you can just have $HOME/src/github.com/bar/foo -- which is less ideal than just $HOME/src/foo, but it's something at least.
  - revel 8y ago
    it's not just that large numbers of projects are a hassle, they make it harder to develop projects in isolation
  - lenkite 8y ago
    I keep the source code for my projects in ~/src and I always set my GOPATH to my home dir. So the special 'go' in the path can be avoided. It will just be ~/src/github.com/... But, yes, I rolled my eyes when learning about GOPATH for the first time.
tptacek 8y ago
I hated it at first but came around over time, to the point where I haven't switched to the modules workflow yet.
- cyphar 8y ago
  I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it. Plus, all of us have got our own GOPATH home-directory workarounds so there's no real point in switching anymore.
  - atombender 8y ago
    That's not true at all. A Go-modules-enabled project can import packages from a non-modules-enabled project that doesn't have Go.mod in it. This was always the case with Glide and Dep, too.
    - cyphar 8y ago
      That's not what I'm talking about. I'm talking about being able to build outside of GOPATH. This requires the top-level project to use go.mod and many don't (like Docker for instance).
      - atombender 8y ago
        But that's not the same thing. You don't have to switch all the projects you work on over to Go modules at the same time, only the projects you want to upgrade. It's entirely possible to migrate incrementally.
  - Merovius 8y ago
    > I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it It seems this gets fixed in Go 1.12 though. AIUI you'll be able to set GOMODULES=on, unset GOPATH and just continue working as before.
- kasey_junk 8y ago
  The modules workflow is a wreck currently. Defer a while if you can.
  - 8y ago
zaphar 8y ago
Pretty much every language has a GOPATH thing. CLASSPATH, PYTHON_PATH, PERL5LIB, ... I never really understand the hate here. It seems more like they didn't hate GOPATH specifically and more that they didn't like not having a package manager.
- pjmlp 8y ago
  The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.
  - kjksf 8y ago
    False. You can put your code anywhere you want and `go build` and `go run` will work just fine. It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.
    - aeijdenberg 8y ago
      False only for very small values of code. ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.
- dagss 8y ago
  GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all. Basically before go 1.11, it was impossible to just do git clone ... somedir cd somedir # build code and run something You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".
  - Merovius 8y ago
    > Basically before go 1.11, it was impossible to just do That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.

Honestly I got the impression no one ever liked gopath.

by cgag 8y ago

Honestly I got the impression no one ever liked gopath.

revskill 8y ago

Because setting environment variables is something most devs like to avoid.

cgag 8y ago
No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.
- cyphar 8y ago
  I have tried several times to fix this problem in the past 5 or 6 years, once with symlinks (which would break quite often -- it's unsurprising that Plan 9 developers wouldn't care too much for handling symlinks correctly :P). The current way I handle it is that $HOME/.local is my GOPATH, and $HOME/src links to $HOME/.local/src. So you can just have $HOME/src/github.com/bar/foo -- which is less ideal than just $HOME/src/foo, but it's something at least.
- revel 8y ago
  it's not just that large numbers of projects are a hassle, they make it harder to develop projects in isolation
- lenkite 8y ago
  I keep the source code for my projects in ~/src and I always set my GOPATH to my home dir. So the special 'go' in the path can be avoided. It will just be ~/src/github.com/... But, yes, I rolled my eyes when learning about GOPATH for the first time.

tptacek 8y ago

I hated it at first but came around over time, to the point where I haven't switched to the modules workflow yet.

cyphar 8y ago
I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it. Plus, all of us have got our own GOPATH home-directory workarounds so there's no real point in switching anymore.
- atombender 8y ago
  That's not true at all. A Go-modules-enabled project can import packages from a non-modules-enabled project that doesn't have Go.mod in it. This was always the case with Glide and Dep, too.
  - cyphar 8y ago
    That's not what I'm talking about. I'm talking about being able to build outside of GOPATH. This requires the top-level project to use go.mod and many don't (like Docker for instance).
    - atombender 8y ago
      But that's not the same thing. You don't have to switch all the projects you work on over to Go modules at the same time, only the projects you want to upgrade. It's entirely possible to migrate incrementally.
- Merovius 8y ago
  > I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it It seems this gets fixed in Go 1.12 though. AIUI you'll be able to set GOMODULES=on, unset GOPATH and just continue working as before.
kasey_junk 8y ago
The modules workflow is a wreck currently. Defer a while if you can.
- 8y ago

zaphar 8y ago

Pretty much every language has a GOPATH thing. CLASSPATH, PYTHON_PATH, PERL5LIB, ... I never really understand the hate here. It seems more like they didn't hate GOPATH specifically and more that they didn't like not having a package manager.

pjmlp 8y ago
The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.
- kjksf 8y ago
  False. You can put your code anywhere you want and `go build` and `go run` will work just fine. It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.
  - aeijdenberg 8y ago
    False only for very small values of code. ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.
dagss 8y ago
GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all. Basically before go 1.11, it was impossible to just do git clone ... somedir cd somedir # build code and run something You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".
- Merovius 8y ago
  > Basically before go 1.11, it was impossible to just do That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.