Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Usage in go:generate Directives #66

Open
terrabitz opened this issue Jan 20, 2021 · 8 comments
Open

Document Usage in go:generate Directives #66

terrabitz opened this issue Jan 20, 2021 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@terrabitz
Copy link

In my Go project, I have some go generate directives that look like this:

//go:generate go run github.com/maxbrunsfeld/counterfeiter/v6 -generate

Unfortunately, this bypasses bingo's installation and pinning process. After a bunch of trial and error, I discovered that you can use use use the bingo-pinned version of the tool like so:

Makefile:

include .bingo/Variables.mk
export

gen: $(COUNTERFEITER)
    go generate ./...

Source Code:

//go:generate $COUNTERFEITER -generate

This might be a bit of a hack, but I wasn't able to find any other examples of using bingo tools in go:generate directives. This might be worth documenting for others who want to use bingo for their code-generation tools.

@bwplotka
Copy link
Owner

bwplotka commented Feb 1, 2021

Thanks, this very good point!

Just curious, if we do something like this //go:generate $COUNTERFEITER -generate why not just //go:generate make gen? (:

Would be easier? 🤔

You are right documenting this would be awesome, help / PRs wanted! 🤗

@bwplotka bwplotka added enhancement New feature or request help wanted Extra attention is needed labels Feb 1, 2021
@terrabitz
Copy link
Author

@bwplotka While this might work for flat projects, I think for nested packages it might not work. I'm pretty surego generate ./... will run each //go:generate directive in that package's working directory. While some generators might be able to do something like mygenerator ./..., there are several that I use that are only able to run in the current working directory.

Moreover, make will fail if it's called in a directory that doesn't contain your Makefile. So if you have the following structure:

mypackage
|- Makefile
|- subpackage
    |- foo.go

and foo.go contains the //go:generate make gen directive, running go generate ./... will result in a No rule to make target 'gen' error since subpackage doesn't contain the Makefile.

@bwplotka
Copy link
Owner

bwplotka commented Feb 2, 2021

Right (:

Then: //go:generate make -C ../ gen would do 🤗

@bwplotka
Copy link
Owner

bwplotka commented Feb 2, 2021

Alternatively //go:generate source ../.bingo/variables.env && ${COUNTERFEITER} -generate if you don't want to use Makefile.

@sevein
Copy link
Contributor

sevein commented Jun 13, 2021

Would it be a good idea to implement a bingo generate subcommand that does something like the following?

tempdir=$(mktemp)
env GOBIN=${tempdir} \
    bingo get -l
env PATH=${GOBIN}:${PATH} \
    go generate [ARGS]

@bwplotka
Copy link
Owner

That might work, what's wrong with adding this to your Makefile / script? 🤔 I might think there is no need to add a separate bingo command for such a simple flow.

We can add that to documentation too (:

@sevein
Copy link
Contributor

sevein commented Jun 15, 2021

That makes sense. I've tried the Makefile approach and it worked great. On the other hand, //go:generate source ... && ... didn't work but I should try again. It'd be nice if users could start using bingo out of the box without this extra level of indirection, e.g. this snippet, it'd be a lot of work to update it.
In any case, I think that you've suggested a good compromise. I'd be happy to put some docs together.

@bwplotka
Copy link
Owner

bwplotka commented Jun 15, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants