I guess this is a question about this issue.
I’ve two base projects - a utility project and a domain project. I’ve got another 14 projects which require one or both of these projects as dependencies. I finally got around to setting up Dep on my projects. However, I immediately hit a wall.
It seems code needs to be pushed to the remote repository for it to be picked up in a
dep ensure. This means workflows would be:
- change base project
- move to project with a base project dependency
dep ensure -update -v
- if bug, restart
If I’ve changed the base package and it results in a bug in a project that depends on it, I’d have to debug by continually pushing the changes I make. I’d then have to run
dep ensure -update for every fix attempt and when I was satisfied I’d fixed the issue I’d have to run
dep ensure -update on all projects t. This seems like a really big overhead.
Hopefully, I’m misunderstanding something. Coming from a Java background I hoped Dep would work in a Maven type way - when the project is built, add code/binary to a single local repository that all other projects refer to ($GOPATH/pkg/dep/sources doesn’t seem to handle local changes).
At the moment, it seems that dep is unsuitable for larger projects and I’m close to removing it again. Does anyone have a workaround (that doesn’t involve wrapping dep)? Or am I doing something wrong?
You’re doing it wrong. If your things are this interdependent, either keep them in the same repo or at least in the same GOPATH and exclude the depency from dep.
They are in the same GOPATH - the vendor dir takes precedence. I’ll try removing the dep dependency tomorrow when I’m back in - perhaps I’ve placed too much faith in depth init.
Dep is great, but in the situation where a part of your program is in a different repo for some reason and needs to evolve in lockstep it just becomes cumbersome.
I try to avoid that situation by erring on the side of larger repos. For something to be a separate repo it should at least be possible to determine if a bug fix works without having it pulled into another repo, imho.
Removing the constraint from the toml file doesn’t to have the desired effect (I had a feeling I tried that yesterday but wanted to sanity check before replying).
I tested the suggestion on a different PC/fresh checkout where only the toml file existed in the project (no existing lock or vendor). Dep ensure still adds the projects to the vendor directory and does not appear to update the vendor directory based on the local state of the projects (either before or after changes are committed).
I don’t think I am doing it wrong - I think the way dep works currently is likely suitable for single/small projects but not very easy to use if you have multiple projects with local dependencies.
We did consider larger repos yesterday too but our projects are really all standalone with completely different functions. It seems a bit shortsighted/bad practice to update our repository structure just so dep works.
Thanks for your reply - I’ll likely back dep out for the moment until issue 935 is addressed.
You need to specifically exclude it. See “ignored” here: https://golang.github.io/dep/docs/Gopkg.toml.html
We had tried this before posting. It wasn’t successful.
By ignoring the packages, it ignores the dep dependencies in those packages also. This leads to the parent project stack tracing due to missing dependency e.g. I have a base logging package - if I ignore the package in the toml file then the logger are inaccessible in other projects. If I don’t ignore the package then I hit the issue described above.
I’ve given up for the time being. Thanks for your help
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.