vendoring

[guybrush]

currently go get github.com/jbenet/go-ipfs/cmd/ipfs doesnt work because of breaking changes in gogoprotobuf, so maybe put deps in a vendor-directory?

https://botbot.me/freenode/ipfs/2014-08-15/?msg=19828336&page=1

[jbenet]

Yeah we need to vendor everything.—
Sent from Mailbox

On Fri, Aug 15, 2014 at 10:11 PM, Patrick Pfeiffer
notifications@github.com wrote:

currently go get github.com/jbenet/go-ipfs/cmd/ipfs doesnt work because of breaking changes in gogoprotobuf, so maybe put deps in a vendor-directory?

https://botbot.me/freenode/ipfs/2014-08-15/?msg=19828336&page=1

Reply to this email directly or view it on GitHub:
#28

[jbenet]

best strategies? the way docker does it?

[guybrush]

im a complete go-noob, without any experience. if you want me to i can put all the deps into github.com/jbenet/go-ipfs/vendor and also change all the import-paths. but it would be the first time i am doing this :D (for example im not sure if i should change import-paths inside vendor-dependencies?)

i am currently looking into all the tools around golang, the dependency-management seems to be kind of rough (comming from nodejs&npm). there are tools to help with vendoring but none of them is ideal.

[whyrusleeping]

I feel like we should have an ipfs github organization for any vendoring we do.

[jbenet]

Am not too keen on premature orgs -- they add a whole bunch of hassle up front. once we have many repos, sure. (For vendoring, we don't need repos. We should be vendoring like Docker + Camlistore do -- cloning into the repo). At least until we can host the code / package manager on IPFS. :)

[guybrush]

i cant wait to host all the things in ipfs, like everything hahaha

also i think vendoring like camli and docker is the best (no git-submodules)

recently i saw another tool that might not be so bad, its used in kubernetes: https://github.com/GoogleCloudPlatform/kubernetes/tree/master/Godeps

[cryptix]

I'd like suggest considering Godeps, too. If all you need is locking your dependencies to specific commits/tags/versions, Godep is a very nice solution. I think docker and camlistore chose their ways because no other mature solution was available when they started.

[whyrusleeping]

my issue with godeps is that its another external tool we have to be dependant on, vendoring the code is seamless and from the users perspective, no extra steps are required.

[whyrusleeping]

I also want to mention that vendoring gives us the power to update our dependencies without having to push any new commits to ipfs, having 400 commits saying "Updating godeps" seems like a messy solution to me

[guybrush]

the reason for vendoring is to update dependencies by commit, isnt it?

you want to be able to checkout a specific commit of ipfs and be sure to get exactly the same binary with go build everytime. even when upstream repositories of dependencies change, like it happened here (the reason why i opened this issue).

[jbenet]

Yeah, we want it to be committed. Let's vendor the way docker + camlistore do it for now.

[whyrusleeping]

Ah, I get it now.

[btc]

Please see: #35

[btc]

Shall we close this issue?