Download release file instead of git clone?

[juansaavedrauy]

I've found a bit confusing to have a cloned repo inside my projects with the go-template file.

Seeing the last release docs, you mention that now it is not necessary to add it as a submodule. But wouldn't it be better to download the tar.gz from the release tag?. The only dependency for this would be gunzip, which is pretty much available everywhere.

I could create a pull request for this.

Fantastic job BTW, I've found this tool extremely useful and insightful.

Regards.

[mbland]

Very cool, glad you're getting some mileage out of it!

Yeah, maybe pulling the zipfile or tarball from the release tag in go-template would be a better idea. I went with git clone initially so that git would be the only dependency outside of bash itself for running the top-level script. An exercise in extreme minimalism, if you will.

If you want to take a shot at a PR, please do! But note the dependencies would be gunzip and curl, wget, or fetch. To pick only one, I'd vote for curl.

[juansaavedrauy]

Given the assumption that the user followed the docs to get the go-template file, curl should be available beforehand.

There could also be more than one go-template file, although at least to me it would be a bit more confusing.

[mbland]

The curl instructions are for the person using go-template checking a new go file into the project, not the person cloning the project and using it for the first time.

That said, yes, we should keep just one go-template, and like you said, chances are most users will have curl and gunzip handy. We can first try a curl | gzip -dc pipe or something, and fall back to git in the remote chance they're not present, perhaps adding a loud message recommending the user installs curl and gunzip. Then we can leave it up to the project owner to trim down the git clone fallback if desired.

[mbland]

Closed by #179 and #180.

[mbland]

@elpaquete Just released v1.6.0 with the go-template tarball download capability. Thanks for the contribution! 🙂