<dir> parameter to dep init is not handled correctly

[sdboyer]

The spec and CLI helptext indicate that dep init should be able to take a directory (relative or absolute) as an argument. If one is not provided, then we instead operate on the cwd.

However, it seems we've been so focused on the cwd case that we've largely neglected explicitly specifying a directory. Specifying an absolute dir seems to work correctly, but relative paths do not; it would appear we're missing a filepath.Abs() somewhere. We need to support relative paths, and add tests for both the absolute and relative path cases.

[anjmao]

What is the use case of dep init being executed not in cwd? In most cases dep init will be used only one time then you need to initialize project to create Gopkg.toml. I don't see this as needed feature, but if it is needed I can take this one for sure.

[niranjan92]

I have got a solution working locally. Let me know if I should submit a PR.

[sdboyer]

@niranjan92 awesome, thank you, please do! 🎉

@anjmao

What is the use case of dep init being executed not in cwd? In most cases dep init will be used only one time then you need to initialize project to create Gopkg.toml. I don't see this as needed feature, but if it is needed I can take this one for sure.

It's more or less the same sort of reasons you'd use git init with a directory argument. The simple case is:

1. cd $GOPATH/src/github.com/myuser
2. dep init somenewproject

The case we haven't thought about much yet, but is valid for use within an internal monorepo is something like

1. git clone https://my.company.com/monorepo.git /path/to/monorepo/root
2. dep init /path/to/monorepo/root/some/subpath/that/needs/projectifying
3. dep init /path/to/monorepo/root/some/other/path/to/make/a/project

This sort of thing might be more common as a step in a company's internal build system; there's no reason the script should have to cd into a directory in order to initiate a project there.

[anjmao]

@sdboyer Thanks, these are good use cases :)
@niranjan92 Maybe next time you can write comment that you are working on issue, so you will be assigned to it, because I also wanted start to work on it :)

[sdboyer]

@anjmao we'll find one for ya!

[niranjan92]

@anjmao I referenced the pull request for that purpose. Next time will comment that I am working on the issue. :)
I will raise a fresh pull request as the previous one was closed while i was trying to resolve cla errors.

[niranjan92]

I am adding the tests in cmd/dep/testdata/harness_tests/init/. However the test is not able to check if the vendor packages got created correctly. Trying to fix that part.

[sdboyer]

@niranjan92 if you can figure out something very easy within the context of the test harness, great. but probably don't try very hard; it may be better to just write a one-off test that checks this specific behavior. we don't want to add a capabilities to the test harness if there's no meaningful reason to write multiple tests that rely on it, and I don't think we'd get much mileage out of a test for this.

[niranjan92]

@sdboyer yeah. I tried adding it to test harness but with no success. I will write a stand alone test to check this behaviour.

My plan is this - create a test folder in /tmp, copying the code and running dep init and testing if the vendor path and .toml and .lock files are generated correctly.

[sdboyer]

@niranjan92 Let's discuss over on the PR 😄