Closed juansaavedrauy closed 7 years ago
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
.
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.
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.
Closed by #179 and #180.
@elpaquete Just released v1.6.0 with the go-template
tarball download capability. Thanks for the contribution! 🙂
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.