deb and rpm packages for Linux

[reegnz]

Provide easy download and install for Linux distributions using dpkg or rpm.

[reegnz]

A simple packaging could be achieved with https://github.com/jordansissel/fpm.

I might give it a go to see how difficult it would be to package tfenv with fpm.

[reegnz]

I have created RPM and DEB packages for tfenv over here: https://github.com/reegnz/terraform-tfenv-package/releases/tag/v2.0.0-1

I would prefer this code to be upstreamed to the tfenv repo though.

[Zordrak]

I've had a look at it, and the code you've produced, but I have concerns.

Firstly, it is not necessarily a good idea to use tfenv as a system level installation in a multi-user system as not only must all users have write permission to the installation directory, but they can conflict with each other over the system default or if one user or job is using a version while another user re-installs it. Rather like rbenv, it is expected to manage a user-level installation that is used instead of the system-level install of terraform. This is highlighted by your comments as to when sudo is required to do certain installations. In fact for Mac it appears the prevalent installation method is homebrew which acknowledges the user-level installation.

Secondly, it's not necessarily the responsibility of a project such as this to provide packages for specific operating systems, that would be the job of the operating system maintainer. While this project is linux-generic and therefore it's possible to provide a generic deb or rpm, they're not guaranteed to work for any given deb-based or rpm-based distribution depending on how that distribution manages its applications and permissions.

Thirdly, the installation of tfenv is entirely complete by cloning the tagged release version or downloading the archive and extracting it from github. There are no system-level settings, no services to configure. As much as it may be valuable in an enterprise platform-delivery project to package the service in a way consistent with your other installations for e.g. Jenkins agents or other CI tooling setup, it's as simple as running fpm against it as your example shows, and you can choose for your own implementation what the installable location should be and how you want it to operate.

Ultimately I'm not sure we would really provide value by deploying an official rpm or dev that declares itself as the authoritative way to install tfenv for operating systems that support them.

[reegnz]

I did some changes to the packaging now to address some of those concerns: https://github.com/reegnz/terraform-tfenv-package/releases/tag/v2.2.0-1

• The multi-user system permissions are solved with a tfenv group who are allowed to write the install directory. Otherwise tfenv install works with sudo.
• I've also split out the install location into /var/lib/tfenv/versions, since for a system-wide install that's more appropriate than downloading to /usr/lib/tfenv/versions.

As to who's allowed to manage the versions: We're using tfenv in deployment environments where we simply use tfenv install to install the versions found in .terraform-version for a given repo checkout. We also plan to pre-bake multiple terraform versions into a VM image with tfenv, allowing to route to the appropriate terraform version, while we also strictly control a subset of allowed terraform versions and disallowing downloads (eg. using tfenv just for easy switching, not downloads).

Eg. we would like to use 0.12.30, 0.13.6 and 0.14.6 on the same server, so we would pre-bake those into a VM image. tfenv seems like a really good tool for switching between them after that.

Regarding packaging: I completely agree that this should mainly be the responsibility of the distribution to provide those packages. For most distros though, there's also a possiblility to distribute packages in a way where distro vendors don't deal with packaging, but the software vendors do (eg. Snap, AppImage, FlatPack). I can live with that though, I imagine that the Homebrew formula is also not maintained by you.

As for the cloning argument, there are scenarios where one would rather not deal with N+1 different installation methods for tools. If my terraform needs can be solved with a distro package of tfenv and then using that to transparently switch between the correct terraform versions, I'd rather skip the rest (eg. not having to use git, curl|bash, or whatever else). I'd imagine a scenario where I can build a self-contained box with a tfenv rpm plus another rpm that installs terraform binaries (multiple versions and providers), so one could also use tfenv for use-cases when you only want to switch between versions, and not download them (think, 'air-gapped' environments with no internet access allowed, running within a datacenter).

I realize this might not be in-scope for this project, but air-gapped environments are most definitely in-scope for terraform enterprise. https://www.hashicorp.com/blog/deploying-terraform-enterprise-in-airgapped-environments

Would be nice for tfenv to be just as flexible regarding use-cases.

I completely respect your choice if you don't want to go down that path though, since it's not just regular dev-tooling what I explained above.

[kvendingoldo]

Will add support in https://github.com/tofuutils/tenv