@mislav Thanks for the feedback! Agreed on all the points but wanted to discuss:

Should we generate a go.mod so that extensions are immediately buildable? We could generate the name of the module as github.com//gh-

I worried that this was assuming too much on behalf of the users, but I am definitely intrigued by doing it. Thinking about the context of all this more this actually seems pretty low risk, so yeah, let's do it.

Should we hardcode github.com though? or try and use whatever host is set?

Will the users know how to build and test the extension in development? Should we include instructions on how to build it, or a Makefile even to make rebuilding easier locally?

I'm worried about this too. I included a hint about go build after doing a local install, but that might not paint a full enough picture of what to do. I can expand that help text for go extensions.

As for make, it's an interesting idea but I'd rather punt. It isn't on Windows by default and I don't think it's worth the complexity -- especially when go build is so succinct.

Should we hardcode github.com though? or try and use whatever host is set?

You could read the DefaultHost from config, which would be github.com normally or the value of GH_HOST if set. But even just hardcoding github.com would be fine with me— we won't always get the module name right; it's just helpful to cover 80% of the cases. In the end, the module name doesn't need to correspond to a real repository on a GitHub instance, since gh extensions don't necessarily need to be go-gettable, and our Action to precompile Go extensions will happily build a Go module with any name.

I included a hint about go build after doing a local install, but that might not paint a full enough picture of what to do. I can expand that help text for go extensions.

We can assume that Go developers will in general know how to use go build, but they might forget that the output binary should be ./gh-<my-extension>(.exe) so that they can run gh <my-extension> while testing their extension. That's why including some hint might be really helpful for users to get started.

Sounds good re: host.

they might forget that the output binary should be ./gh-(.exe)

This is precisely what go build creates. In my hint I was over-explicit and said go build -o %s but without -o go uses the name of the directory housing main.go as the name for the output executable. on windows it appends .exe automatically. As far as I can tell, the developer literally only needs to gh install . and go build.

This is ready for re-review. Here's the current state of the user output:

cc @mislav

I've:

• changed the main.go template to invoke a REST call with go-gh
• made it clear that we downloaded go dependencies
• did end to end QA for all three extension types

Not going to merge immediately until we confirm whether we are ok with it quietly shipping this week or if we want to wait to merge until next week's loud ship