7 ms·

He forgot to mention how programmers need to add each project directory to $GOPATH to be able to include files stored in project subdirectories. Talk about a b

by Mooby 14y ago

He forgot to mention how programmers need to add each project directory to $GOPATH to be able to include files stored in project subdirectories. Talk about a braindead idea.

burke 14y ago
I interpret this as encouragement to use fully-qualified package names (eg: https://github.com/burke/zeus/blob/master/go/zeusmaster/zeusmaster.go#L8-L14 https://github.com/burke/zeus/blob/master/go/zeusmaster/zeus...), which I don't really have a problem with. Go code is nothing if not explicit.
- troutwine 14y ago
  How do you manage dependency versions with a fully-qualified package name?
  - skybrian 14y ago
    There's no explicit versioning unless you do a fork (which effectively puts the version into the import path). When doing open source work, you just assume that the latest version works. If it doesn't, you can complain and check out an earlier version instead (locally), or in the worst case, fork the code until it's fixed and change your import statements to point to the forked version. For a company, it makes sense to check your GOPATH into your own source control system, so everyone has the same version of the open source libraries you're using. Then upgrading some open source libraries to a new version is a commit like any other change.
- Mooby 14y ago
  That approach is nice and all if we are dealing with modules which we wish to reuse. If instead we would like to organize our source tree following a deep directory structure, we are forced to screw around with $GOPATH, which is a braindead idea.
  - drivebyacct2 14y ago
    Huh? You can literally just set $GOPATH to any directory. The only stipulation is that you put your source code in a 'src' folder. That's literally all you have to do. I'm going to go out on a limb and guess you're one of the people that cries in IRC and can't be bothered to read either of the pages that detail the design and use of the `go` tool.
  - marshray 14y ago
    You keep asserting that this $GOPATH is "braindead" but you provide no meaningful criticism of it or suggest any better alternatives. I haven't messed with Go, but nothing about the idea of defining a path for source modules sounds braindead on its face to me. I certainly would give the benefit of any doubt to the designers of Go over some random troll.
    - Mooby 14y ago
      These are not source modules I'm talking about. If it was only necessary to set $GOPATH to point to source modules then everything would be fine. The problem is that go requires that $GOPATH points to a project's source tree to be able to build it, if the project is organized to store other go source files in subdirectories. We aren't talking about packages or modules intended to be reused in other programs. We are talking about how source code trees are organized.
      - marshray 14y ago
        The problem is that go requires that $GOPATH points to a project's source tree to be able to build it How is that different than the /I ${INCLUDE} path of C/C++ compilers (and many other languages)?
enneff 14y ago
That's not true. You're supposed to add a workspace path to GOPATH, and keep all your packages in there. You can use multiple workspaces (add more directories to GOPATH), but that's not a requirement. This screencast might help: http://www.youtube.com/watch?v=XCsL89YtqCs http://www.youtube.com/watch?v=XCsL89YtqCs
- Mooby 14y ago
  You started your post by claiming it wasn't true, but you proceeded to say that yes, it is in fact true. As it is stated in the screencast, a programmer needs to add the workspace to $GOPATH to be able to build the source. That means that for each project being developed in Go, you need to add the path to that project to $GOPATH to be able to build it. That is a very poor way to do develop software.
  - agentS 14y ago
    Or, you could have multiple projects in a single workspace... Personally, I keep 2; one for external packages, and one for ones I'm working on.
  - enneff 14y ago
    No, that's not true. You just keep all your projects in a single workspace (as I do), and their namespaces keep them separate.
    - Mooby 14y ago
      You repeat yourself yet again. How exactly can you claim with a straight face that a workspace doesn't need to be referred to in $GOPATH, and then proceed to claim that you only need to set $GOPATH to a directory which contains those workspaces? You start off your post by claiming it's not true, but then you repeat exactly what I said. Are you joking?
drivebyacct2 14y ago
That's not even true. You can use the compiler and linkers to your hearts content. What you meant to say was, their braindead idea was that if you want to be able to trivially use ANY go program or library on GitHub, you can use $GOPATH and the go tool [1] and not fuck around with autotools and makefiles. If you're into S&M, no one is stopping you from using the core pieces of the `go` tool by hand. [1]: ALL of my code can be download, built and run with: `go get github.com/myname/myproject; myproject` (I have $GOPATH/bin on my path)
- Mooby 14y ago
  I'm not talking about gc. I'm talking about go. You know, the program which is extensively marketed as the only program which is required to build and run Go programs, and the standard and default way to deal with Go, from installing third-party packages and running your program through an interpreter. Referring to gc makes as much sense as referring to gccgo.
  - drivebyacct2 14y ago
    What do you want? You don't want to use the `go` tool, DON'T USE IT. Seriously, the alternative that you are implying that you want is already available to you.
  - agentS 14y ago
    Not sure if you know this (or anything about Go), but the go tool just uses a bunch of other programs to accomplish what it does (including git, bzr, the compiler and the linker). If you want to do your own thing, you're free to ignore the rest of the community in this respect, and create your own build mechanism. In fact, if you pass the "-x" flag to the go tool, you can even see how its accomplishing what its accomplishing; which might help you write this better build tool.

by Mooby 14y ago

He forgot to mention how programmers need to add each project directory to $GOPATH to be able to include files stored in project subdirectories. Talk about a braindead idea.

burke 14y ago

I interpret this as encouragement to use fully-qualified package names (eg: https://github.com/burke/zeus/blob/master/go/zeusmaster/zeusmaster.go#L8-L14 https://github.com/burke/zeus/blob/master/go/zeusmaster/zeus...), which I don't really have a problem with. Go code is nothing if not explicit.

troutwine 14y ago
How do you manage dependency versions with a fully-qualified package name?
- skybrian 14y ago
  There's no explicit versioning unless you do a fork (which effectively puts the version into the import path). When doing open source work, you just assume that the latest version works. If it doesn't, you can complain and check out an earlier version instead (locally), or in the worst case, fork the code until it's fixed and change your import statements to point to the forked version. For a company, it makes sense to check your GOPATH into your own source control system, so everyone has the same version of the open source libraries you're using. Then upgrading some open source libraries to a new version is a commit like any other change.
Mooby 14y ago
That approach is nice and all if we are dealing with modules which we wish to reuse. If instead we would like to organize our source tree following a deep directory structure, we are forced to screw around with $GOPATH, which is a braindead idea.
- drivebyacct2 14y ago
  Huh? You can literally just set $GOPATH to any directory. The only stipulation is that you put your source code in a 'src' folder. That's literally all you have to do. I'm going to go out on a limb and guess you're one of the people that cries in IRC and can't be bothered to read either of the pages that detail the design and use of the `go` tool.
- marshray 14y ago
  You keep asserting that this $GOPATH is "braindead" but you provide no meaningful criticism of it or suggest any better alternatives. I haven't messed with Go, but nothing about the idea of defining a path for source modules sounds braindead on its face to me. I certainly would give the benefit of any doubt to the designers of Go over some random troll.
  - Mooby 14y ago
    These are not source modules I'm talking about. If it was only necessary to set $GOPATH to point to source modules then everything would be fine. The problem is that go requires that $GOPATH points to a project's source tree to be able to build it, if the project is organized to store other go source files in subdirectories. We aren't talking about packages or modules intended to be reused in other programs. We are talking about how source code trees are organized.
    - marshray 14y ago
      The problem is that go requires that $GOPATH points to a project's source tree to be able to build it How is that different than the /I ${INCLUDE} path of C/C++ compilers (and many other languages)?

enneff 14y ago

That's not true. You're supposed to add a workspace path to GOPATH, and keep all your packages in there. You can use multiple workspaces (add more directories to GOPATH), but that's not a requirement. This screencast might help: http://www.youtube.com/watch?v=XCsL89YtqCs http://www.youtube.com/watch?v=XCsL89YtqCs

Mooby 14y ago
You started your post by claiming it wasn't true, but you proceeded to say that yes, it is in fact true. As it is stated in the screencast, a programmer needs to add the workspace to $GOPATH to be able to build the source. That means that for each project being developed in Go, you need to add the path to that project to $GOPATH to be able to build it. That is a very poor way to do develop software.
- agentS 14y ago
  Or, you could have multiple projects in a single workspace... Personally, I keep 2; one for external packages, and one for ones I'm working on.
- enneff 14y ago
  No, that's not true. You just keep all your projects in a single workspace (as I do), and their namespaces keep them separate.
  - Mooby 14y ago
    You repeat yourself yet again. How exactly can you claim with a straight face that a workspace doesn't need to be referred to in $GOPATH, and then proceed to claim that you only need to set $GOPATH to a directory which contains those workspaces? You start off your post by claiming it's not true, but then you repeat exactly what I said. Are you joking?

drivebyacct2 14y ago

That's not even true. You can use the compiler and linkers to your hearts content. What you meant to say was, their braindead idea was that if you want to be able to trivially use ANY go program or library on GitHub, you can use $GOPATH and the go tool [1] and not fuck around with autotools and makefiles. If you're into S&M, no one is stopping you from using the core pieces of the `go` tool by hand. [1]: ALL of my code can be download, built and run with: `go get github.com/myname/myproject; myproject` (I have $GOPATH/bin on my path)

Mooby 14y ago
I'm not talking about gc. I'm talking about go. You know, the program which is extensively marketed as the only program which is required to build and run Go programs, and the standard and default way to deal with Go, from installing third-party packages and running your program through an interpreter. Referring to gc makes as much sense as referring to gccgo.
- drivebyacct2 14y ago
  What do you want? You don't want to use the `go` tool, DON'T USE IT. Seriously, the alternative that you are implying that you want is already available to you.
- agentS 14y ago
  Not sure if you know this (or anything about Go), but the go tool just uses a bunch of other programs to accomplish what it does (including git, bzr, the compiler and the linker). If you want to do your own thing, you're free to ignore the rest of the community in this respect, and create your own build mechanism. In fact, if you pass the "-x" flag to the go tool, you can even see how its accomplishing what its accomplishing; which might help you write this better build tool.