6 ms·

Python has a list of locations to look for projects (modules) in (sys.path) and by default includes the working directory as the first item in that list. Go ha

Python has a list of locations to look for projects (modules) in (sys.path) and by default includes the working directory as the first item in that list. Go has a list of locations to look for projects (packages) in ($GOPATH) and by default does not include the working directory. Unlike Python's sys.path, $GOPATH normally only contains a single value. Python's behavior is similar to $PATH on Windows while Go's behavior is similar to $PATH on Unix. There are pros and cons to each default value but either language can be overridden to have the other's behavior if you desire. I personally quite like having a single unified $GOPATH for all of my source.

Manishearth 10y ago
> There are pros and cons to each default value but either language can be overridden to have the other's behavior if you desire. How? With Python I can release a package with code like `import foo from .` in it. This will not work in Go, a GOPATH package must import things from subdirectories via GOPATH. At least, this was the case the last time I checked.
- schmichael 10y ago
  True, you must put your source within a directory named src.
- thegeekpirate 10y ago
  Vendoring https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJ... https://blog.gopheracademy.com/advent-2015/vendor-folder/ https://blog.gopheracademy.com/advent-2015/vendor-folder/
  - shadowmint 10y ago
    Vendoring only works inside a GOPATH; if you're outside the GOPATH, the vendor/ folder is ignored. https://github.com/golang/go/issues/14566 https://github.com/golang/go/issues/14566 There are many problems with running outside GOPATH. Among others, there's no caching of built object files, so everything is much slower than it should be (go build, go test, and so on). Vendoring is pretty low on the list of problems. It may be that GOPATH should be reconsidered but if so it should be done as a whole change, not just one piece at a time, like @bradfitz said above. The solution for now is to use GOPATH. > rsc closed this on 6 Dec 2016 Once the new dependency tool is done, it seems like GOPATH will be increasingly irrelevant with vendored dependencies and proper tooling. (You may also be interested in this extended and active discussion on getting rid of GOPATH; https://github.com/golang/go/issues/17271 https://github.com/golang/go/issues/17271)
    - thegeekpirate 10y ago
      You're absolutely correct—I just tested it, and I'll be damned. That's what I get for never playing around with it, and had (wrongly) assumed that this would have been one of the most basic features of vendoring. I appreciate the correction!
  - Manishearth 10y ago
    Yeah, vendoring doesn't fix this problem as the sibling comment says. To be clear, I'm aware the team is aware of the inadequacies of the current system and is working on fixing it -- just saying that this doesn't work well now :)
    - thegeekpirate 10y ago
      Yep no worries—I was wondering why you wouldn't have known such a "basic" thing, and now I'm more knowledgeable because of it =)
rat87 10y ago
I think sys.path defaults to PYTHONPATH (+interpreter relative lib path) if it exists

Manishearth 10y ago

> There are pros and cons to each default value but either language can be overridden to have the other's behavior if you desire. How? With Python I can release a package with code like `import foo from .` in it. This will not work in Go, a GOPATH package must import things from subdirectories via GOPATH. At least, this was the case the last time I checked.

schmichael 10y ago
True, you must put your source within a directory named src.
thegeekpirate 10y ago
Vendoring https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJ... https://blog.gopheracademy.com/advent-2015/vendor-folder/ https://blog.gopheracademy.com/advent-2015/vendor-folder/
- shadowmint 10y ago
  Vendoring only works inside a GOPATH; if you're outside the GOPATH, the vendor/ folder is ignored. https://github.com/golang/go/issues/14566 https://github.com/golang/go/issues/14566 There are many problems with running outside GOPATH. Among others, there's no caching of built object files, so everything is much slower than it should be (go build, go test, and so on). Vendoring is pretty low on the list of problems. It may be that GOPATH should be reconsidered but if so it should be done as a whole change, not just one piece at a time, like @bradfitz said above. The solution for now is to use GOPATH. > rsc closed this on 6 Dec 2016 Once the new dependency tool is done, it seems like GOPATH will be increasingly irrelevant with vendored dependencies and proper tooling. (You may also be interested in this extended and active discussion on getting rid of GOPATH; https://github.com/golang/go/issues/17271 https://github.com/golang/go/issues/17271)
  - thegeekpirate 10y ago
    You're absolutely correct—I just tested it, and I'll be damned. That's what I get for never playing around with it, and had (wrongly) assumed that this would have been one of the most basic features of vendoring. I appreciate the correction!
- Manishearth 10y ago
  Yeah, vendoring doesn't fix this problem as the sibling comment says. To be clear, I'm aware the team is aware of the inadequacies of the current system and is working on fixing it -- just saying that this doesn't work well now :)
  - thegeekpirate 10y ago
    Yep no worries—I was wondering why you wouldn't have known such a "basic" thing, and now I'm more knowledgeable because of it =)

rat87 10y ago

I think sys.path defaults to PYTHONPATH (+interpreter relative lib path) if it exists