command for rewriting import paths

[fredr]

It would be nice if I could rewrite all dependencies of my package to the corresponding nut-version. Something similar to running godep save -r github.com/fredr/mypackage/... that will rewrite all import paths in github.com/fredr/mypackage.

This would be to make sure I haven't imported locked packages form the GOPATH instead of the nut vendor dir. (i.e goimports probably chooses the GOPATH path)

And if it also could report any non-vendored packages would be nice (maybe that should be it's own command)

Makes sense?

[owenthereal]

Makes sense?

:+1:

[owenthereal]

I'm thinking of providing a flag that users could choose to fix import paths for source

[fredr]

cool, are you thinking a global flag, or a flag to the install command?

[owenthereal]

I'm thinking a flag to the install command since that's the only command for now related to rewriting import paths.

[eikenb]

If you add this please consider a corresponding command that will change the import paths back to the unvendored packages. This would make path rewriting more or less feature equivalent to tools that mess with the GOPATH.

[owenthereal]

@eikenb:

If you add this please consider a corresponding command that will change the import paths back to the unvendored packages.

This shouldn't be hard to implement. But rewriting import paths and vendoring dependencies are the whole points of nut. I'd need to understand more why people would choose to vendor dependencies with nut but want to migrate away later.

[fredr]

I can think of one thing, and that is "unvendoring" a package when developing and testing new code in that package. Other package managers like npm and bower use a link command for that. https://docs.npmjs.com/cli/link

[dvirsky]

Actually replacing the vendored package with a symlink and keeping the importing code in the parent app using the vendored path seems like a nice idea.

[owenthereal]

I wonder how this will work. All your source's import paths are referring to the vendored dependencies, e.g., github/jingweno/nut/internal/github.com/foo/bar. Unvendoring dependencies will cause the build to fail.

[dvirsky]

@jingweno let's take your case. "unvendoring" does the following:

1. rmdir github.com/jingweno/nut/internal/github.com/foo/bar
2. if $GOPATH/github.com/foo/bar does not exist - go get github.com/foo/bar
3. ln -s $GOPATH/github.com/foo/bar github.com/jingweno/nut/internal/github.com/fo/bar

that's about it.

[owenthereal]

I may not make myself clear. Dependencies are vendored and in the source, we're referring to dependencies like:

package main

import(
  "github.com/jingweno/nut/internal/github.com/foo/bar"
)

func main() {
  ...
}

If we unvendor the dependencies into $GOPATH/github.com/foo/bar without rewriting their import paths as well, the build will fail for main. That's why I want to understand more why people would want this.

[dvirsky]

the way I see it, unvendoring means checking out a pristine copy of those packages with the manifest's current revision, into GOPATH, not copying the vendored copy back there. It's mostly useful IMO for first-party dependencies, i.e. stuff you're still actively working on (something like pip install -e). Personally I don't want to vendor those at all, if they're in my control, I want to directly import them from my own git repo.

[owenthereal]

Personally I don't want to vendor those at all, if they're in my control, I want to directly import them from my own git repo.

nut doesn't enforce a project to vendor all dependencies. There could be some dependencies outside of ./internal/.... Just refer to those dependencies like you usually do without nut. Am I missing anything here?

[dvirsky]

No, that's precisely why I prefer nut to godep :) to me the issue discussed here is not important, I was just commenting on the technical aspects of how to implement it.

[eikenb]

I was only talking about the import paths. That if you provide a command to rewrite them to use the vendored package, you provide a corresponding command to rewrite them back to the non-vendored versions. It wouldn't affect what packages were in the vendored area (the internal directory).

My main use case is being able to switch to the versions of packages you have installed on your GOPATH and back. This can be useful when testing new versions and the like. I do this with godep currently by using its path manipulation method (using the godep command). Given the communities leaning toward rewriting as the long term solution I'd like to see the ability to switch back and forth maintained.

[dvirsky]

I've added rewriting as a separate command (nut vendor) in my own fork if anyone wants it. I don't think it should be a separate command so I didn't make a PR of it. https://github.com/EverythingMe/nut/commit/f10e84ac3a74a8588523a3a9d323803207b55a02