4 ms·

Use dep, which they're planning to add to the official tools like 'go get'. Then add your vendor directory to your gitignore, and you're done.

kuschku 9y ago
I don’t want a vendor directory in the first place, how do I avoid that? I want it to just automatically do its stuff just like maven/gradle/sbt work, and not deal with any damn dependencies. I want it to automatically set the dependency path, and handle incremental compiles. If people claim it has so much better tooling than Java, then I expect at least it to work as well as Java’s tooling.
- hellcow 9y ago
  I'm trying to understand your complaint. Obviously you'll need a vendor directory somewhere containing the source code of your dependencies. Maven places them outside the project's root dir (defaults to ~/.m2/repository), whereas Go puts them inside the project's root dir. Tomato-tomato. They have to exist on your system somewhere.
  - kuschku 9y ago
    > They have to exist on your system somewhere. Yes, but they shouldn’t be something I’d have to ever care about. Whenever I type "build", the build tool should automatically manage the dependencies and invoke the build process.
- weberc2 9y ago
  You're confused, Java's tooling is more complex/less intuitive. It doesn't matter where the dependency data lives on your system; it's completely transparent to you.
  - kuschku 9y ago
    > It doesn't matter where the dependency data lives on your system; it's completely transparent to you. Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening. If I want to add a preprocessor, I import it the same way that I’d import a normal dependency, just with another directive – `compile 'com.jakewharton:butterknife:8.8.1'` vs `annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'`. This is something I really miss in the JS and Go and C and C++ world. It all just works.
    - weberc2 9y ago
      > Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). This seems like a ridiculous edge case to optimize for. It's rare and trivially corrected. > Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening. You don't have to configure a $GOPATH in Go. If you don't specify it, it defaults to $HOME/go. Just use `dep` to manage your versioned dependencies or `go get` if you're prototyping. Unlike Gradle, there is no scripting language to learn--static binaries and native dependencies are supported with no extra configuration, and everything is fast without a complicated daemon to install.

kuschku 9y ago

I don’t want a vendor directory in the first place, how do I avoid that? I want it to just automatically do its stuff just like maven/gradle/sbt work, and not deal with any damn dependencies. I want it to automatically set the dependency path, and handle incremental compiles. If people claim it has so much better tooling than Java, then I expect at least it to work as well as Java’s tooling.

hellcow 9y ago
I'm trying to understand your complaint. Obviously you'll need a vendor directory somewhere containing the source code of your dependencies. Maven places them outside the project's root dir (defaults to ~/.m2/repository), whereas Go puts them inside the project's root dir. Tomato-tomato. They have to exist on your system somewhere.
- kuschku 9y ago
  > They have to exist on your system somewhere. Yes, but they shouldn’t be something I’d have to ever care about. Whenever I type "build", the build tool should automatically manage the dependencies and invoke the build process.
weberc2 9y ago
You're confused, Java's tooling is more complex/less intuitive. It doesn't matter where the dependency data lives on your system; it's completely transparent to you.
- kuschku 9y ago
  > It doesn't matter where the dependency data lives on your system; it's completely transparent to you. Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening. If I want to add a preprocessor, I import it the same way that I’d import a normal dependency, just with another directive – `compile 'com.jakewharton:butterknife:8.8.1'` vs `annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'`. This is something I really miss in the JS and Go and C and C++ world. It all just works.
  - weberc2 9y ago
    > Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). This seems like a ridiculous edge case to optimize for. It's rare and trivially corrected. > Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening. You don't have to configure a $GOPATH in Go. If you don't specify it, it defaults to $HOME/go. Just use `dep` to manage your versioned dependencies or `go get` if you're prototyping. Unlike Gradle, there is no scripting language to learn--static binaries and native dependencies are supported with no extra configuration, and everything is fast without a complicated daemon to install.