Binary dependency

[fzerorubigd]

I want to use something like go-bindata (https://github.com/jteeuwen/go-bindata) (my code is not open source but the concept is similar, a simple code (and sample data in my case) generator with a library to use that generated stuff)
there is a tool and a library, (a code generator) , both are depend to each other.

Binary must be in my project bin folder (or vendor/bin not a big deal) and the library is in my venor directory.
Currently I use symlink, to link the main package inside the src folder (and Symlinks are already rejected as solution in #91 ) what is the best way to handle this case? (copy is not an option since the library is not maintain by my team)

[davecheney]

I'm sorry, I don't understand what you are asking for. I think I understand the background, but not what gb does not do today.

[fzerorubigd]

Sorry :)
The question is, how I can vendor something like go-bindata in a gb project? the library is inside vendor, but the binary is not available.

[davecheney]

Thanks. I think I understand now.

Because gb does not build code that is not referenced by source inside $PROJECT/src, if you have go-bindata at $PROJECT/vendor/src/github.com/x/go-bindata it will never be built.

This is an interesting use case. I don't have an answer for you right now, but as you're probably using something like a Makefile or grunt to automate this, one workaround for the moment would be to

cd $PROJECT/vendor; gb build .../go-bindata

Which will leave $PROJECT/vendor/bin/go-bindata.

This should be pretty easy to manage with a Makefile.

[chakrit]

@davecheney I was looking for this as well.

For comparison, in node.js, all (explicitly declared) binaries are installed into node_modules/.bin. This allows you to version-lock your toolset as well by making sure all your scripts/makefile reference the local binaries instead of global ones. Also means that dev teams do not need anything else besides node and npm to start working as soon as they clone the project.

The same can be accomplished with other $GOPATH-manipulation tool since theoretically a bin/ will still be created and you can invoke go install explicitly otherwise.

For GB, I think adding a gb vendor install command that will compiles and install an explicitly specified (and pre-vendored) package into vendor/bin would solve this use case nicely. You get the same version locking you have for dependencies, but for the toolset as well. Devs don't need to install anything globally (or in their $GOPATH) besides go and gb. Even gb itself could be vendored in this manner provided there's a bootstrap script.

[davecheney]

For GB, I think adding a gb vendor install command that will compiles and install an explicitly specified (and pre-vendored) package into vendor/bin would solve this use case nicely.

You can already do this

% cd $PROJECT/vendor && gb build

Please let me know if I have misunderstood your question

[divoxx]

I have the same issue. Some vendored packages that I explicitly included in my project have binaries that helps with the tooling and build of my application.

For example, go-bindata can embed assets and migrate can manage database migrations.

Would be really cool to either have gb vendor build (or another cmd) to build the binaries in my vendor folder but only for the packages that I explicitly vendored, i.e. excluding recursive fetches. We can probably do that fairly easy by reading the manifest file, correct?

The problem with cd $PROJECT/vendor && gb build is that it will add a vendor/vendor folder and unnecessarily recurse dependencies like that. Also, it should be simple and standard to build binary dependencies with a simple single command.

[davecheney]

Would be really cool to either have gb vendor build (or another cmd) to build the binaries in my vendor folder but only for the packages that I explicitly vendored, i.e. excluding recursive fetches. We can probably do that fairly easy by reading the manifest file, correct?

@divoxx I believe you have that today

pushd $PROJECT/vendor && gb build && popd

will do the same as gb vendor build

The problem with cd $PROJECT/vendor && gb build is that it will add a vendor/vendor folder

This sounds like a bug.

[divoxx]

@davecheney sorry to disagree but I don't think that's a good solution :)

Let me expand:

If I vendor a package github.com/x/y/z it will fetch the repo github.com/x/y and the dependencies of github.com/x/y/z but a gb build inside the vendor/ folder will try to build all the fetched code, not just the packages that I explicitly vendored.

It will fail if a package, say github.com/x/y/w, have dependencies that haven't been vendored. Even if it compiles it will probably build binaries that I don't even care about, from deps of deps.

Not to mention that it would create a separate copy of pkgs under the vendor folder.

[davecheney]

@divoxx you can work around this by gb vendor fetching those additional dependencies.

You can also do gb build $PACKAGE inside vendor/ to avoid the situation you describe.

gb vendor purge may remove them again, but I think it's broken at the moment so that's a moot point.

I'm sorry I don't have a better answer for you at the moment.

[fzerorubigd]

@davecheney Sorry to bring this up again.
For a workaround, I use symlink, but with the new importer, the symlink workaround is not working anymore :/
I there any hope for this to be done?

[davecheney]

Could you please log a new issue with details and I'll investigate.

On Thu, 31 Dec 2015, 18:28 fzerorubigd notifications@github.com wrote:

@davecheney https://github.com/davecheney Sorry to bring this up again.
For a workaround, I use symlink, but with the new importer, the symlink
workaround is not working anymore :/
I there any hope for this to be done?

—
Reply to this email directly or view it on GitHub
#100 (comment).

[fzerorubigd]

About symlink? I already did and it is closed now : #91 I agree with you about symlinks, and not supporting it. but I use it as a workaround for current (#100) issue.
Is this "not supporting symlinks in the new refactor" is an issue? or its by design?

[davecheney]

I'm not sure I understand. Did I break something with #511 ? If so, please log a bug with what you see and what you expect so I can investigate. Thanks.

On 31 Dec 2015, at 20:58, fzerorubigd notifications@github.com wrote:

About symlink? I already did and it is closed now : #91 I agree with you about symlinks, and not supporting it. but I use it as a workaround for this issue.
Is this "not supporting symlinks in the new refactor" is an issue? or its by design?

—
Reply to this email directly or view it on GitHub.

[fzerorubigd]

Please see #528 for detail.