Open terrabitz opened 3 years ago
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 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.
Right (:
Then: //go:generate make -C ../ gen
would do 🤗
Alternatively //go:generate source ../.bingo/variables.env && ${COUNTERFEITER} -generate
if you don't want to use Makefile.
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]
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 (:
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.
Please do! Thanks (: Kind Regards, Bartek PÅ‚otka @.***)
On Tue, Jun 15, 2021 at 7:36 PM Jesús GarcÃa Crespo < @.***> wrote:
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 https://github.com/vmware-tanzu/octant/blob/a7e566c54573ab9ae5991b785edad93f5d61e6e3/internal/cluster/cluster.go#L42-L51, it'd be a lot of work to make that work. In any case, I think that you've suggested a good compromise. I'd be happy to put some docs together.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bwplotka/bingo/issues/66#issuecomment-861700146, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA3O4TYLRAS7LZK7Y2CQLTS6FRHANCNFSM4WKOTA4A .
In my Go project, I have some go generate directives that look like this:
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:
Source Code:
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.