Dep: Support for ProjectRoot to be on 3rd level after domain?

Created on 22 Nov 2017  ยท  8Comments  ยท  Source: golang/dep

What version of dep are you using (dep version)?

v0.3.2-83-g13df556

What dep command did you run?

Trying to use init:

$ dep init -v
Getting direct dependencies...
Checked 2 directories for packages.
Found 2 direct dependencies.
Root project is "company.io/organisation/team/service"
 1 transitively valid internal packages
 2 external packages imported from 2 projects
(0)   โœ“ select (root)
(1)   โ† no more versions of company.io/organisation/team to try; begin backtrack
  โœ— solving failed

Solver wall times by segment:
     b-list-versions: 1.280307098s
     b-source-exists: 558.051607ms
         select-root:    296.192ยตs
               other:     70.186ยตs
            new-atom:      1.995ยตs
  b-deduce-proj-root:      1.716ยตs

  TOTAL: 1.838728794s

init failed: unable to solve the dependency graph: Solving failure: remote repository at https://company.io/organisation/team.git does not exist, or is inaccessible: : exit status 128

Trying to use directly ensure by providing the following Gopkg.toml:

[[constraint]]
  branch = "master"
  name = "github.com/gorilla/mux"

[[constraint]]
  branch = "master"
  name = "company.io/organisation/team/library"
  source = "company.io/organisation/team/library.git"
$ dep ensure -v
The following issues were found in Gopkg.toml:

  โœ— the name for "company.io/organisation/team/library" should be changed to "company.io/organisation/team"

ProjectRoot name validation failed

What did you expect to see?

That the package name company.io/organisation/team/library is detected as ProjectRoot. But instead, it tried to load Package company.io/organisation/team.git and probably assumed library as internal package, but that's not the case.

What did you see instead?

Error that my dependency is not valid.

Some notes

We're using gitlab, where you can have (indefinitly?) subgroups, so this way you can have a domain.io/group/subgroup/repo structure (or deeper). Is this 2 level path for ProjectRoot enforced by dep or golang?

And if yes, why is it enforced? Because, so far I can follow:

  • try to load company.io/organisation/team/service
  • if it's a repo, treat it as ProjectRoot -> end
  • if it's not there, assume it's a package and continue
  • try to load company.io/organisation/team
  • if it's a repo, treat it as ProjectRoot and service is an internal package -> end
  • and so on ...

Directory structure for context:

. // = $GOPATH
โ””โ”€โ”€ src
    โ””โ”€โ”€ company.io
        โ””โ”€โ”€ organisation
            โ”œโ”€โ”€ team
            โ”‚ย ย  โ”œโ”€โ”€ library
            โ”‚ย ย  โ”‚ย ย  โ”œโ”€โ”€ store
            โ”‚ย ย  โ”‚ย ย  โ”œโ”€โ”€ testcases
            โ”‚ย ย  โ”‚ย ย  โ””โ”€โ”€ vendor
            โ”‚ย ย  โ”‚ย ย      โ”œโ”€โ”€ github.com
            โ”‚ย ย  โ”‚ย ย      โ”‚ย ย  โ””โ”€โ”€ gorilla
            โ”‚ย ย  โ”‚ย ย      โ”‚ย ย      โ”œโ”€โ”€ context
            โ”‚ย ย  โ”‚ย ย      โ”‚ย ย      โ””โ”€โ”€ mux
            โ”‚ย ย  โ”‚ย ย      โ””โ”€โ”€ gopkg.in
            โ”‚ย ย  โ”‚ย ย          โ””โ”€โ”€ yaml.v2
            โ”‚ย ย  โ””โ”€โ”€ service
            โ”‚ย ย      โ”œโ”€โ”€ testcases
            โ”‚ย ย  โ”‚ย ย  โ””โ”€โ”€ vendor
            โ””โ”€โ”€ team2
                โ”œโ”€โ”€ ...

And in service/main.go the import is:

import (
    "log"
    "net/http"
    "company.io/organisation/team/library"
)

Most helpful comment

The problem I am seeing in these comments is that your gitlab project has a subgroup and Dep does not recognize that. The reason is that a subgroup, in this case "repo", is private. This is based on Gitlab's security policy that subgroups are always private and changing that is not supported.

the name for "gitlab.internal/team/project/repo" should be changed to "gitlab.internal/team/project"

To get the above to work, in your Gopkg.tml all you need to do is add ".git" to the end of the url like this:

[[constraint]]
name = "gitlab.internal/team/project/repo.git"

That URL above with .git would be the same for the import in your Go file.

This a known issue with gitlab. At least that is what the developers of Dep say.

All 8 comments

I ran into the same issue.
It would be nice to know what the plan is to address this. Because it might put constraints on how gitlab users can layout their organisations and still benefit from dep.

hi folks - i appreciate the detailed writeup and thoughtful response, but unfortunately, this is a gitlab problem - see https://github.com/golang/dep/issues/1355#issuecomment-343630104 . it seems they've merged a fix, but i don't know if it's available in a released version yet.

I don't think it is gitlab problem
Have the same issue while putting next constraint to the Gopkg.toml

[[constraint]]
  branch = "master"
  name = "gitlab.internal/team/project/repo"
  source = "[email protected]:team/project/repo.git"

dep ensure -v exits with error

The following issues were found in Gopkg.toml:

  โœ— the name for "gitlab.internal/team/project/repo" should be changed to "gitlab.internal/team/project"

ProjectRoot name validation failed

Here is related testcase in dep - https://github.com/golang/dep/blob/master/manifest_test.go#L604
It refuses constraints with names deeper than 2 levels after domain

If i change name in constraint like this (removing "team")

[[constraint]]
  branch = "master"
  name = "gitlab.internal/project/repo"
  source = "[email protected]:team/project/repo.git"

everything is ok

@sdboyer Looks like it is still an issues?

I created a feature proposal at gitlab a few days ago. I know, that currently gitlab won't return the correct go-get meta information, when you're not authorized, e.g. your targeted repo is private and wants your credentials. Everything should be pretty good explained in that proposal about this exact case. And if this applies to you, feel free to help implement it ;)

But if this doesn't apply to you (e.g. your repo is public), then you have to dig further, mainly you have to check, if the recieved go-get meta information is correct. As far as I understand dep is using, or behaving same as, go get. So when you do a go get -v your/repo/path/somewhere, you'll get the output of the meta information this command has recieved.

In our case go get works fine for go get -v gitlab.internal/team/project/repo. We are using ssh keys for authorization. But dep ensure does not. Description is in my comment above

Having the same issue here. I have a private project on third level and ran into the issue with go get at first. Once I configured git to use ssh by running

git config --global url."[email protected]:".insteadOf "https://gitlab.com/"

go get now works however it seems that dep is ignoring that completely on dep init and I get the error as if it was trying to use https

Did I miss anything or is this an issue in dep?

+1

The problem I am seeing in these comments is that your gitlab project has a subgroup and Dep does not recognize that. The reason is that a subgroup, in this case "repo", is private. This is based on Gitlab's security policy that subgroups are always private and changing that is not supported.

the name for "gitlab.internal/team/project/repo" should be changed to "gitlab.internal/team/project"

To get the above to work, in your Gopkg.tml all you need to do is add ".git" to the end of the url like this:

[[constraint]]
name = "gitlab.internal/team/project/repo.git"

That URL above with .git would be the same for the import in your Go file.

This a known issue with gitlab. At least that is what the developers of Dep say.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sdboyer picture sdboyer  ยท  3Comments

deejross picture deejross  ยท  3Comments

abeMedia picture abeMedia  ยท  3Comments

michael-go picture michael-go  ยท  3Comments

carolynvs picture carolynvs  ยท  3Comments