Dep: Support empty ProjectRoot

[fabulous-gopher]

_From @sdboyer on March 20, 2017 16:3_

golang/dep#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]

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]

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]

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

[Freeaqingme]

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]

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.

[ascherkus]

The use case I'm interested in here is similar to others where I'd like to have a monorepo containing multiple internal projects, but have a single set of third-party dependencies stored under src/vendor/.

New to the codebase but I've been trying to hack on this to see what might be possible. It seems to work for some sample test cases (see below) but not all others. I'm curious if anyone has thoughts as to where I should be looking to properly support this use case.

Example working layout:

src/
    mycompany/
              foo/
              bar/
    vendor/
           github.com/...
           golang.org/...

I've been able to support the above use case by hacking things up to remove the empty ProjectRoot checks:

diff --git a/context.go b/context.go
index 0ababd4c..2e4f5637 100644
--- a/context.go
+++ b/context.go
@@ -318,7 +318,9 @@ func (c *Ctx) ImportForAbs(path string) (string, error) {
        }
        if isPrefix {
                if len(path) <= len(srcprefix) {
-                       return "", errors.New("dep does not currently support using GOPATH/src as the project root")
+                       // HACK: Support empty ProjectRoot (#417).
+                       // return "", errors.New("dep does not currently support using GOPATH/src as the project root")
+                       return "", nil
                }

                // filepath.ToSlash because we're dealing with an import path now,
diff --git a/gps/solver.go b/gps/solver.go
index 74e77414..c81ce9f5 100644
--- a/gps/solver.go
+++ b/gps/solver.go
@@ -172,9 +172,10 @@ func (params SolveParameters) toRootdata() (rootdata, error) {
        if params.RootDir == "" {
                return rootdata{}, badOptsFailure("params must specify a non-empty root directory")
        }
-       if params.RootPackageTree.ImportRoot == "" {
-               return rootdata{}, badOptsFailure("params must include a non-empty import root")
-       }
+       // HACK: Support empty ProjectRoot (#417).
+       // if params.RootPackageTree.ImportRoot == "" {
+       //      return rootdata{}, badOptsFailure("params must include a non-empty import root")
+       // }
        if len(params.RootPackageTree.Packages) == 0 {
                return rootdata{}, badOptsFailure("at least one package must be present in the PackageTree")
        }

Example non-working layout:

src/
    mycompany.org/
              foo/
              bar/
    vendor/
           github.com/...
           golang.org/...

I believe mycompany.org doesn't get filtered out and the HTTP metadata check fails as a result. Have yet to track down where that filtering logic lies -- would love to get some pointers!

[ascherkus]

Answering my own question here .. but it looks like the reason why the mycompany case "works" is due to IsStandardImportPath() treating that code as a standard library, meaning it filters out all import statements that reference mycompany/..., leaving all the truly external import statements and then dep works as intended.

It seems like a bit of hack to rely on the standard import logic. One path I've explored is whether using RootManifest.IgnoredPackages() is the right way to ignore all local imports (i.e., add all local subdirs in the GOPATH root). That seems to get past the package list step but fails at the deducing step (it still seems to try and deduce the type via HTTP and fails).

[Freeaqingme]

For further reference, I assume this issue was closed due to #2166.

[kevinburke]

Hey, yes, that was rather a brute force approach, I can reopen.

[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!