4 ms·

The issue of disappearing vendors can largely be solved using godep and distributing binaries, but I don't feel like any language I've used has an effective mec

The issue of disappearing vendors can largely be solved using godep and distributing binaries, but I don't feel like any language I've used has an effective mechanism for coupling unit testing with dependency management. Wouldn't it make sense to be able to test your code in advance of updating a dependency to see the how's and why's of its failures?

skybrian 12y ago
Checking in your deps handles that. If your tests don't pass, don't check in the change. But this requires source control systems that can store the files for many projects at a time. (See today's other discussion about git.) [1] [1] http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/# http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-...
- pbh101 12y ago
  Depending on specific versions of dependencies should also handle that, without needing to check in all dependencies. This is the approach generally taken when using Maven and related tools.
  - nulltype 12y ago
    The only difference is that finding the dependencies can be a pain if they changed location, or github is down, or the specific version isn't a specific git commit or something like that. Since there's no real difference, it doesn't really matter if you check in deps or have specific versions in a config file, either solution solves the underlying problem of having non-precise dependencies (i.e. just a github repo, or a version selector like >= 2.6)
aikah 12y ago
> The issue of disappearing vendors can largely be solved using godep Godep isn't "canon". There lies the problem. There should be no need for godep,the library dependecy issue should be solved once and for all by the go team so everybody uses the same library dependency manager. Vendoring dependencies solves nothing. Should I bundle these dependencies If I put my libs on github? and what if a dep has a bug? how do I know what version was used if I want to fix the lib myself? All that stuff stinks. I like Go but these are serious issues that will backfire, because other plateforms have been there and done that...
- twblalock 12y ago
  Have other platforms done this? I'm having trouble thinking of a language toolkit that has dependency management built by the core team. All of these solutions are third-party, they have just become the de-facto standard: Java uses Maven or Gradle: third party Python uses pip: third party Ruby uses gems: third party Node.js uses npm: third party I'm sure I'm missing some, but this seems to be the norm. Go just hasn't been around long enough for a single third-party solution to become the de facto standard.
  - sigmaml 12y ago
    > I'm having trouble thinking of a language toolkit that has dependency management built by the core team. Rust + Cargo.
    - Gurkenmaster 12y ago
      Ceylon + Herd
  - asveikau 12y ago
    I think this is something of a shibolleth for a certain type of programmer: * Thinks that dependency management of third party libraries is an important problem in their project. * Demands that there be one centralized repo and method for that. No alternatives! Maybe it shows that I am a C fan, but I kind of skew on the opposite of this spectrum. Really the most important part of your project is how you import a library? Really? Even out of chaos, like a language with no native support for it, it's a small chore and you get over it quickly. But I am not one of the types that agonizes over it, as I guess go people are.
    - comex 12y ago
      I'm a C fan, too, but not when it comes to dependencies. In a world where using someone's library typically requires one or more of (a) having everyone compiling your code also manually compile the library, (b) hoping the library has found its way into N different OS package managers, and (c) vendoring requiring manual maintenance, you end up with a lot of real world C and C++ code reimplementing basic things that would be better done in a library, because importing a library is too much work. This sucks - certainly it's possible for libraries to be too small, dependency graphs too convoluted, and you can see some of that on npm, but C/C++ are so far on the other end of the spectrum that it's hardly worth thinking of.

skybrian 12y ago

Checking in your deps handles that. If your tests don't pass, don't check in the change. But this requires source control systems that can store the files for many projects at a time. (See today's other discussion about git.) [1] [1] http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/# http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-...

pbh101 12y ago
Depending on specific versions of dependencies should also handle that, without needing to check in all dependencies. This is the approach generally taken when using Maven and related tools.
- nulltype 12y ago
  The only difference is that finding the dependencies can be a pain if they changed location, or github is down, or the specific version isn't a specific git commit or something like that. Since there's no real difference, it doesn't really matter if you check in deps or have specific versions in a config file, either solution solves the underlying problem of having non-precise dependencies (i.e. just a github repo, or a version selector like >= 2.6)

aikah 12y ago

> The issue of disappearing vendors can largely be solved using godep Godep isn't "canon". There lies the problem. There should be no need for godep,the library dependecy issue should be solved once and for all by the go team so everybody uses the same library dependency manager. Vendoring dependencies solves nothing. Should I bundle these dependencies If I put my libs on github? and what if a dep has a bug? how do I know what version was used if I want to fix the lib myself? All that stuff stinks. I like Go but these are serious issues that will backfire, because other plateforms have been there and done that...

twblalock 12y ago
Have other platforms done this? I'm having trouble thinking of a language toolkit that has dependency management built by the core team. All of these solutions are third-party, they have just become the de-facto standard: Java uses Maven or Gradle: third party Python uses pip: third party Ruby uses gems: third party Node.js uses npm: third party I'm sure I'm missing some, but this seems to be the norm. Go just hasn't been around long enough for a single third-party solution to become the de facto standard.
- sigmaml 12y ago
  > I'm having trouble thinking of a language toolkit that has dependency management built by the core team. Rust + Cargo.
  - Gurkenmaster 12y ago
    Ceylon + Herd
- asveikau 12y ago
  I think this is something of a shibolleth for a certain type of programmer: * Thinks that dependency management of third party libraries is an important problem in their project. * Demands that there be one centralized repo and method for that. No alternatives! Maybe it shows that I am a C fan, but I kind of skew on the opposite of this spectrum. Really the most important part of your project is how you import a library? Really? Even out of chaos, like a language with no native support for it, it's a small chore and you get over it quickly. But I am not one of the types that agonizes over it, as I guess go people are.
  - comex 12y ago
    I'm a C fan, too, but not when it comes to dependencies. In a world where using someone's library typically requires one or more of (a) having everyone compiling your code also manually compile the library, (b) hoping the library has found its way into N different OS package managers, and (c) vendoring requiring manual maintenance, you end up with a lot of real world C and C++ code reimplementing basic things that would be better done in a library, because importing a library is too much work. This sucks - certainly it's possible for libraries to be too small, dependency graphs too convoluted, and you can see some of that on npm, but C/C++ are so far on the other end of the spectrum that it's hardly worth thinking of.