hey @lorengordon - thanks for the contribution. we're reluctant to add further dependencies into the image, especially ones that are only maintained by a single person. 🙂 if the community is very interested in it, we'll reconsider our stance but for now I'd recommend you to build your image on top of this one.

@peterdeme There is also asdf, to address the package availability and maintenance concern.

for now I'd recommend you to build your image on top of this one.

Please see the linked issue. The whole point of adding a user-space package management tool is to avoid the need to build and maintain an image publishing pipeline and associated infrastructure. That is not a trivial suggestion; there is significant operational burden there for private projects, and little to no business value. Whereas adding a tiny package to the spacelift image is quite trivial.

I definitely understand the reluctance to add packages. But this image is used as a CI service, and CI images quite commonly have rather large manifests to address the large variety of use cases and tool versions. Using a package manager like mise or asdf helps maintain the slimness of the image, exactly because users can use the tool to install packages instead of baking them into the image!

But this image is used as a CI service, and CI images quite commonly have rather large manifests to address the large variety of use cases and tool versions.

To be fair, we don't really see Spacelift as a generic CI service like Jenkins or TeamCity. I think this assumption makes a lot of sense there but not necessarily for plain Terraform deployments.

Using a package manager like mise or asdf helps maintain the slimness of the image, exactly because users can use the tool to install packages instead of baking them into the image!

How would you use it by the way? Would you install some tooling in as a pre-init hook?

In any case, I reopened the GitHub issue to see if anyone else feels strongly about this.

How would you use it by the way? Would you install some tooling in as a pre-init hook?

Yes, exactly, probably added to a stack using a context. I see the ability to manage tool versions as a key component of the package manager. Including terraform, opentofu, terragrunt, tflint, aws-cli, opa, infracost, etc. Even python and other languages.

Personally, I just don't like relying on image versions for that kind of consistency and control. Too many layers, too much abstraction, too many potential combinatorics for requirements across different projects. I much prefer managing it at the project level. I mean, Spacelift could replace the several different images they maintain with a single one, and run asdf/mise themselves in the "preparation" step of a stack run...

I know Spacelift offers some capability for managing at least the terraform/opentofu/terragrunt versions at the stack-level. But I think it's only those tools? Where it's just a builtin capability of asdf/mise for any tool in their registry. The support from renovatebot to update the tool versions is also quite useful.

EDIT: Oh, and the "workflow tool" stack option! Currently requires custom images to install the tool at all, or complicated before_init hooks. With a package manager like asdf/mise, no problem.