3 ms·

You can also "vendor", there's support in Go for it.

• xienze 10y ago
  Which is a poor solution since it involves checking all your dependencies into source control. There's no reason why you shouldn't be able to have a file that lists all your dependencies and versions and lets you pull them down on-demand.
  • geoka9 10y ago
    For sure, I was just pointing out a workaround.
  • prodigal_erik 10y ago
    If you can't build and deploy your own system without a piece of code, you should not be relying on the goodwill of any third party to keep it available for you with no SLA. A good build system is a deterministic function of its input (a commit from your repo) and can run offline.
• notheguyouthink 10y ago
  Vendor has some very basic problems though, and honestly i think it's unusable due to that. It's a ticking time bomb, imo. In short, types, especially interfaces in returns, are strictly bound to their location which might be a vendor. If two libraries are using vendors[1] then the types are inherently incompatible between the two libraries. My most common point of failure for this is running into Logging interfaces that return themselves. That interface is completely incompatible with the other package's vendored logger, and so you have to have two instances of a logger - one for each package. [1]: (ie, they both have a main package and a library package, so they both have vendors). It's to the point where if you have a main and a library, like many repos, you should simply move the main to another repo entirely.. which sucks, imo.