In Go, the path information is part of your import statement. Therefore it would be helpful to preserve the path information available to "retrieve" statements.
Given a library:
"foo/bar.a" where "foo" is a namespace, and "bar.a" is the name of the actual library.
When I publish using the following statement:
fig --publish bar/1.0 --resource=pkg/foo/bar.a --append="GOPATH=@/pkg//foo/bar.a"
And when I have a package.fig in my project that both includes the package bar/1.0 and has a retrieve statement:
retrieve GOPATH->pkg
config default
include bar/1.0
end
Then I should see the following directory structure in my project directory that contained the package.fig above. Note that the directory structure for 'foo/bar.a' was preserved.
$ tree .
.
├── package.fig
└── pkg
└── foo
└── bar.a
And double-slashes should be stripped when printing and using environment variables.
$ fig -g GOPATH
/home/username/.fighome/repos/bar/1.0/foo/bar.a
In Go, the path information is part of your import statement. Therefore it would be helpful to preserve the path information available to "retrieve" statements.
Given a library: "foo/bar.a" where "foo" is a namespace, and "bar.a" is the name of the actual library.
When I publish using the following statement: fig --publish bar/1.0 --resource=pkg/foo/bar.a --append="GOPATH=@/pkg//foo/bar.a"
And when I have a package.fig in my project that both includes the package bar/1.0 and has a retrieve statement: retrieve GOPATH->pkg config default include bar/1.0 end
Then I should see the following directory structure in my project directory that contained the package.fig above. Note that the directory structure for 'foo/bar.a' was preserved. $ tree . . ├── package.fig └── pkg └── foo └── bar.a
And double-slashes should be stripped when printing and using environment variables. $ fig -g GOPATH /home/username/.fighome/repos/bar/1.0/foo/bar.a