Skip to content
This repository was archived by the owner on Sep 9, 2020. It is now read-only.

Support for ProjectRoot to be on 3rd level after domain? #1396

Closed
dionysius opened this issue Nov 22, 2017 · 8 comments
Closed

Support for ProjectRoot to be on 3rd level after domain? #1396

dionysius opened this issue Nov 22, 2017 · 8 comments

Comments

@dionysius
Copy link

dionysius commented Nov 22, 2017

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"
)
@ralf-cestusio
Copy link

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.

@sdboyer
Copy link
Member

sdboyer commented Nov 28, 2017

hi folks - i appreciate the detailed writeup and thoughtful response, but unfortunately, this is a gitlab problem - see #1355 (comment) . it seems they've merged a fix, but i don't know if it's available in a released version yet.

@sdboyer sdboyer closed this as completed Nov 28, 2017
@burkostya
Copy link

burkostya commented Feb 14, 2018

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?

@dionysius
Copy link
Author

dionysius commented Feb 14, 2018

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.

@burkostya
Copy link

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

@alethenorio
Copy link

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?

@vmpartner
Copy link

+1

@ajbazz
Copy link

ajbazz commented Jun 22, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants