7 ms·

> Importing from live git paths seems like the worst possible solution to this. Then don't do it. Check your dependencies into your repositories and update imp

> Importing from live git paths seems like the worst possible solution to this. Then don't do it. Check your dependencies into your repositories and update import paths.

hdevalence 13y ago
What happens when the dependencies have bugfixes or security flaws? Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question?
- nknighthb 13y ago
  You make an explicit, knowledgable decision to update the dependency, like you should be doing with all software in a production environment.
  - frowaway001 13y ago
    Why is this supposed to involve tons of stupid stuff instead of adjusting a version number accordingly?
- mseepgood 13y ago
  > What happens when the dependencies have bugfixes or security flaws? Copy the new version into the repository, run the import rewriting script and check it in. > Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question? Because you want to have full control over your dependencies. What if the author introduces a breaking change or removes the repository from the internet? Do you want to risk your business by being at the mercy of someone else's repository?
  - gmjosack 13y ago
    What about when the library you want to use has a non-compatible license for distributing it with your source code?
  - deleted 13y ago
    [deleted]
- burntsushi 13y ago
  Update them when you want. Just like you would with a package manager. If you need to stay up to date, then have something monitor their commit logs.
eropple 13y ago
Checking dependencies into my repositories is worse. It hugely increases friction for upgrades (which means fewer people will do it) and pushes monitoring for updates down onto the consumer rather than the maintainer (which means some people will forget and get owned). This is the problem that Maven, RubyGems, etc. have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution. And that seems to be a regular occurrence in Go: the willing championing of bad but "simple" solutions (error codes as far as the eye can see!) under the mistaken assumption that things are complex just to be complex rather than that they're complex because they solve a bigger problem.
- burntsushi 13y ago
  > It hugely increases friction for upgrades I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. > have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution By a large margin, I spend the least amount of time configuring my Go packages for release than for any other language.
  - eropple 13y ago
    I can "imagine" a lot of things, too, or I can change one number in a pom or a Gemfile. Because the infrastructure is both predictable and standardized. (And doesn't require barfing your dependencies' changes into your source tree to do it. Funny, that.) "Write a script" is a poor solution for an endemic problem.
    - burntsushi 13y ago
      It's not an excuse. As I said, I spend much less time configuring Go packages than I do for packages written in other languages.
      - eropple 13y ago
        Your claim strains my credulity to the snapping point. Please explain how manual operations are faster (and no more error prone than a transitive dependency solver). Bear in mind that it is a one field change in a Gemfile or Composer or Maven/SBT/whatever-Java.
schmichael 13y ago
You don't actually import from live git paths. You import from your local filesystem ($GOPATH). The compiler doesn't care how code gets into $GOPATH. A single tool, "go get", pulls code directly from 3rd parties and puts it in $GOPATH. If you're uncomfortable or frustrated using "go get" there are a number of 3rd party options.
- burntsushi 13y ago
  I think you may have responded to the wrong comment...

> Importing from live git paths seems like the worst possible solution to this. Then don't do it. Check your dependencies into your repositories and update import paths.

hdevalence 13y ago

What happens when the dependencies have bugfixes or security flaws? Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question?

nknighthb 13y ago
You make an explicit, knowledgable decision to update the dependency, like you should be doing with all software in a production environment.
- frowaway001 13y ago
  Why is this supposed to involve tons of stupid stuff instead of adjusting a version number accordingly?
mseepgood 13y ago
> What happens when the dependencies have bugfixes or security flaws? Copy the new version into the repository, run the import rewriting script and check it in. > Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question? Because you want to have full control over your dependencies. What if the author introduces a breaking change or removes the repository from the internet? Do you want to risk your business by being at the mercy of someone else's repository?
- gmjosack 13y ago
  What about when the library you want to use has a non-compatible license for distributing it with your source code?
- deleted 13y ago
  [deleted]
burntsushi 13y ago
Update them when you want. Just like you would with a package manager. If you need to stay up to date, then have something monitor their commit logs.

eropple 13y ago

Checking dependencies into my repositories is worse. It hugely increases friction for upgrades (which means fewer people will do it) and pushes monitoring for updates down onto the consumer rather than the maintainer (which means some people will forget and get owned). This is the problem that Maven, RubyGems, etc. have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution. And that seems to be a regular occurrence in Go: the willing championing of bad but "simple" solutions (error codes as far as the eye can see!) under the mistaken assumption that things are complex just to be complex rather than that they're complex because they solve a bigger problem.

burntsushi 13y ago
> It hugely increases friction for upgrades I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. > have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution By a large margin, I spend the least amount of time configuring my Go packages for release than for any other language.
- eropple 13y ago
  I can "imagine" a lot of things, too, or I can change one number in a pom or a Gemfile. Because the infrastructure is both predictable and standardized. (And doesn't require barfing your dependencies' changes into your source tree to do it. Funny, that.) "Write a script" is a poor solution for an endemic problem.
  - burntsushi 13y ago
    It's not an excuse. As I said, I spend much less time configuring Go packages than I do for packages written in other languages.
    - eropple 13y ago
      Your claim strains my credulity to the snapping point. Please explain how manual operations are faster (and no more error prone than a transitive dependency solver). Bear in mind that it is a one field change in a Gemfile or Composer or Maven/SBT/whatever-Java.

schmichael 13y ago

You don't actually import from live git paths. You import from your local filesystem ($GOPATH). The compiler doesn't care how code gets into $GOPATH. A single tool, "go get", pulls code directly from 3rd parties and puts it in $GOPATH. If you're uncomfortable or frustrated using "go get" there are a number of 3rd party options.

burntsushi 13y ago
I think you may have responded to the wrong comment...