3 ms·
> It's either that, or you pin the version you want in your own fork of the package. Which is not an unreasonable solution to the bitrot problem. And if that p
by furyofantares 14y ago
> It's either that, or you pin the version you want in your own fork of the package. Which is not an unreasonable solution to the bitrot problem.
And if that package references another package on github understandably I need to pin it too, but do I also need to modify all of the imports in the original third party package I wanted to reference the pinned dependency?
- burntsushi 14y ago> And if that package references another package on github understandably I need to pin it too Only if you want to. You don't have to. > but do I also need to modify all of the imports in the original third party package I wanted to reference the pinned dependency? Yes, but it's trivial: find ./ -name '*.go' -print0 | xargs -0 \ sed -i 's#github.com/BurntSushi/wingo#github.com/YourName/wingo#g'
- furyofantares 14y ago> Only if you want to. You don't have to. I guess I don't understand why it's expected that I would run production code that imports from a third party automatically. I don't want to deploy updates some random person committed today to some third party package I'm using or some package it depends on, so if I want to use a third party package I have to recursively pin it and its dependencies and recursively modify import statements.
- burntsushi 14y agoThen don't run `go get` to update your local packages.