Closed dhaavi closed 3 years ago
Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!
I recently ran into a very interesting issue that arose from using dep:
I am developing a big project in Go with multiple repos. Every repo has their own
dep
state and vendor directory. These import paths are excluded indep
in order to allow local development in both repos at the same time - one depends on the other.I used a package that binds data to
context.Context
, but I was unable to get that data back from theContext
in the other repo. As far as I understand this is because both repos have their own version of the key used to get/set data with theContext
, because the lib is essentially compiled two times into the binary, although it is the exact same version.I resolved the issue by creating a wrapper function in order to always read and write data from/to the
Context
from the same repo.But now I am wondering if this behavior will give me even weirder bugs in the future. Is there a suggested approach how to handle this? Can I "deduplicate" packages when compiling?
Read about the concrete issue in more detail here: https://github.com/gorilla/mux/issues/498