Open paralin opened 6 years ago
ran into this just now, can we please merge this?
+1, I'm also running into this now
Out of curiosity, why is it happening? Why does the symlink already exist?
Out of curiosity, why is it happening? Why does the symlink already exist?
What's the use case for this command? Could you provide an example?
What's the use case for this command? Could you provide an example?
I don't actually know what the use case is.
I thought I had a valid use-case for it, but upon further investigation it doesn't work for my use case.
I was using it to try and package my local source 'tree' for a Docker deploy. At a naive level it works for this task, but I was wanting it to incorporate all my gx-go link
ed dependancies, which I don't think it does.
but I was wanting it to incorporate all my
gx-go link
ed dependancies, which I don't think it does.
Ok, yes my question was aimed at that connection with gx-go link
, like why do you use this command instead of gx-go link
or how do they interact.
@whyrusleeping is probably the best person to answer this as he committed 002072b56a1f1f6788d4918bd0a3f3edd205ff58
This explanation is possibly incorrect, given that I haven't fully run gx-go devcopy
through its paces.
My understanding is:
gx-go link
symlinks your $GOPATH/src/gx/[hash]/[package] directory to your $GOPATH/src/[dvcs] path. For hacking on dependancies.gx-go devcopy
creates a vendor directory, in your local path, that contains a copy of the dependancies. I.e. a vendor copy of all the code. It obtains all of the code directly from gx, it downloads it all again. This would be useful if you want to tar up the directory and send it to someone else. They don't need to obtain any dependancies to compile go-ipfs
(not from dcvs, and not from gx).
This will prevent errors about the directory already existing in the vendor tree.