New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support empty ProjectRoot #417

Open
fabulous-gopher opened this Issue Apr 21, 2017 · 5 comments

Comments

Projects
None yet
7 participants
@fabulous-gopher
Copy link

fabulous-gopher commented Apr 21, 2017

From @sdboyer on March 20, 2017 16:3

#313 highlighted an issue where things don't behave very well if ProjectRoot is empty. This seems like a case we should explicitly support, though. This is kind of a stub issue for all that, but two quick thoughts:

  • One set of work is refactoring ListPackages() and PackageTree.ToReachMap() to work differently when the root is empty
  • The other is changing the solver's root-project-checking behaviors to ensure everything matches up.

Copied from original issue: sdboyer/gps#197

@ror6ax

This comment has been minimized.

Copy link

ror6ax commented Jan 11, 2018

Hi! Thanks for the awesome tool!

I want to ask for update on this one. What is the status of this in 2018? It's unclear from the linked issues whether it's still a planned feature, or when is it to be exected.

Meanwhile most of the manuals out there just tell you to 'dep init' as if you can do it wherever you want, which is a great source of confusion.

In the meantime, I'd like to suggest appending "ctx.DetectProjectGOPATH: /home/ror6ax/testproject is not within a known GOPATH" with something like "To use dep, please move your code to GOPATH/src." So far, as a first-timer I would have no idea what is going on.

@retnuh

This comment has been minimized.

Copy link

retnuh commented Jan 26, 2018

I'm also curious to know, I saw a 0.4.0 tag floating around yesterday, but no release. I'm specifically interested in the issue called out in #836 which was closed, pointing here.

Our use case is similar to that in #836, but we want to make sure our third_party tools have a consistent set of dependencies, and it's very not-obvious (other than somewhat crazy Makefile heroics) how we can add specific Gopkg/Golock files to third-party checkouts. This is the somewhat odd case of needing a third party tool (the protobuf go generator, specifically) as part of the build toolchain, and we want to make sure we have reproducible builds, so we need to pin the third_party repo (& it's deps) to a specific hash.

@schmidtw

This comment has been minimized.

Copy link

schmidtw commented Feb 20, 2018

Any ETA on this landing? This defect seems to break some pretty common work flow patterns.

joe94 added a commit to Comcast/tr1d1um that referenced this issue Feb 21, 2018

@Freeaqingme

This comment has been minimized.

Copy link

Freeaqingme commented Apr 1, 2018

Yep, same here. I've been wanting to migrate to dep, but there doesn't appear to be a nice way to get it working (I'll gladly accept a workaround if there's one :))

@retnuh

This comment has been minimized.

Copy link

retnuh commented Apr 3, 2018

I just copy in a dummy main.go to get started, that uses cobra or viper or some library I know I'll eventually be using. I then do dep init and can then just get on with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment