Why sprig-slim instead of just sprig?

[ghostsquad]

This is mainly a question for @andreynering - Why sprig slim and not just use upstream sprig?

[andreynering]

Hi @ghostsquad,

Good question, by the way.

Task used sprig directly for some time, and I eventually decided to fork into slim-sprig.

I consider sprig to be too bloated for a template package. It imports too many packages and have too many functions, some which does not make any sense to have as a template helper.

There's a good number of external dependencies. Compare slim-sprig (only test dependencies) with sprig.

The crypto package was particularly problematic. The problem is not only that it imports the package, but that it uses too many methods from it. And since crypto is a heavy thing, it added a lot to the compilation time and binary size. Also, encrypting/decrypting things does not make any sense in Task anyway, so it was useless.

At the time I got about 23% of the binary size reduced with the change, along with faster compilation. And well, it's not that the size matters that much, but I really like to have dependencies at a minimum when reasonable (BTW I hate the whole node_modules thing in the JS world 🙂 ).

Apparently, at least one big project agree with me.

---

I'll also take the opportunity to answer your 3 other issues: go-task/slim-sprig#6, go-task/slim-sprig#7 and go-task/slim-sprig#8.

My usual answer to these kind of issues is that it should be done upstream at sprig, so we can pull later and the two project do not diverge too much (other than slim-sprig not having some functions). But since sprig seems a bit slow in development we can eventually decide to do one of:

1. Accept divergences and start adding new functions to slim-sprig
2. Add these functions to the Task project itself

[ghostsquad]

At the time I got Masterminds/sprig#114 (comment)

We are talking about a 2MB binary. This definitely is peanuts when it comes to not having to maintain your own library. One of the reasons I'm asking is because there are actually many methods in sprig that I find super helpful. I would much prefer to write go than to write bash/shell scripts. The more complicated the task, or likelihood that I'll have dependencies on external binaries, the harder it becomes to maintain scripts, and thus tasks.

I was considering making my own library actually, and going with the https://github.com/loggr approach. Basically separate out chunks of the library into separate repos so that you can pull in what you want. What do you think?

[ghostsquad]

though, writing a new library wouldn't actually do anything, because I'd still likely want to include many of the same functions. Looking at sprigs dependencies:

https://github.com/Masterminds/goutils v1.1.1 (no sub dependencies)
https://github.com/Masterminds/semver v3.1.1 (no sub dependencies)
https://github.com/google/uuid v1.1.1  (no sub dependencies)
https://github.com/huandu/xstrings v1.3.1  (no sub dependencies)
github.com/imdario/mergo v0.3.11
  - require gopkg.in/yaml.v2
https://github.com/mitchellh/copystructure v1.0.0
  - require github.com/mitchellh/reflectwalk v1.0.2
https://github.com/shopspring/decimal v1.2.0 (no sub dependencies)
github.com/spf13/cast v1.3.1
  - require (
	https://github.com/davecgh/go-spew v1.1.1 // indirect
	https://github.com/pmezard/go-difflib v1.0.0 // indirect
	https://github.com/stretchr/testify v1.2.2
    )
https://github.com/stretchr/testify v1.5.1
golang.org/x/crypto v0.0.0-20200414173820-0848c9571904
  - require (
	golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2
	golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1
	golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1
     )

All in all, this actually isn't that much.