Dep: Use local (GOPATH or just file) as source

[stevenroose]

When testing new branches one is working on in projects that use dep, it would be useful to be able to without having to push them to the public.

Specifying the branch doesn't work (it seems that dep doesn't look in GOPATH for branches, but remotely (why?)), adding the path of the package in my machine in source also doesn't work.

Either would work:

• let branch also include local branches in GOPATH
• let source be a path
• have a new variable (either global or per-constraint) include-gopath

[juliandroid]

Any logical reasons that is not supported?

[stevenroose]

I guess because it wouldn't work on someone elses computer. So I think this would best be implemented as an "override" section.

[juliandroid]

dep supports git, but what I want to do is actually checkout my local copy and tell dep to use that, so I can do active, local development and test before committing and pushing those changes.
I don't want committing and pushing every debugging "Printf", just because dep doesn't support file://

Current workflow:

1. Checkout, common for my App, package X maintained by my company (aka company.com/packagex).
2. Copy that package to App/vendor directory manually (not in public space, i.e. not in github, so cannot be downloaded by dep ensure)
3. Develop the App, run dep ensure to handle all the google/github sources.
4. Change package X source code, commit, push, go to step 1.

This process is exhausting.
I don't see why dep cannot download packages from random git repositories and also why doesn't support file:// schema, so you can point to local source where one can develop at least.

[stevenroose]

That's exactly what I wanted this feature for. Right now, if my main
package depends on another of my repos, in order to work on the other repo
and test in the main package, I have to work inside the vendor/
directory. Or upload to a branch and specify the branch in dep and have dep
pull everything again, which is really slow.

On Fri, Apr 13, 2018 at 10:47 AM, juliandroid [e-mail]
wrote:

dep supports git, but what I want to do is actually checkout my local copy
and tell dep to use that, so I can do active, local development and test
before committing and pushing those changes.
I don't want committing and pushing every debugging "Printf", just because
dep doesn't support file://

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/1747#issuecomment-381068819, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA0F3NY3joFCXMRbsOy1zonIBC9MB0OTks5toGY2gaJpZM4Slahu
.

[davejohnston]

Yep - I have the same requirement. It would make life a-lot easier if I could use a local branch. This is something glide was able to support, and has caused the most pain since switching.
https://glide.readthedocs.io/en/latest/commands/#glide-mirror.

I wonder as a workaround after running dep ensure you can symlink your local repo - but it's not ideal.

[niondir]

Actually when ever I use dep locally - not before checking in but to simply work on my project where everything is local - dep ensure gives so much time that I search for issues like this :)

I still think something like "dep ensure -local" to not query any remote repositories would be useful for everyone. Of course I need to run dep ensure without the -local flag before pushing code and on CI. But for local dev it would speed up things a lot!

For locally missing dependencies it could either just error (would be fine) or download the remote repository at the time being.

[guiguan]

Yes, please add this feature to make local dev & testing much easier. Something like yarn link would be awesome.

[dmrajkarthick]

Any update on this feature? It's getting very difficult when developing multiple dependent repos and not being able to test it locally.

[juliandroid]

This project is practically dead, you should migrate to go modules: https://blog.golang.org/modules2019

[mvdan]

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!