Show HN: Shello – Wrangle Environment Variables
A lightweight mac app for managing environment variables locally. No auth, no network requests, no usage tracking... just files on your machine.
(
9 comments
| 2 points
| on HN
)
When we've set this up in the past, it was a bit of a pain to have local envs, and cloud envs, and the build system needs to get the cloud ones, etc. etc.
Though I could see adding “teams” features to shello that help with syncing and cloud environments
You can then commit all the config (including the secret identifiers) and it all just works so long as you're authenticated with your secret storage system.
We do this for the live configuration as well in line with Gitops and find it to work well.
If you don't want to use a cloud secret manager you can also use something like https://github.com/getsops/sops to commit the encrypted secrets safely
> Well, Shello there ;)
> Why hasn't someone thought of this before? Once I added the bash shell function (see their website) it was super easy to swap between sets of envars. This will make life as a developer a bit more enjoyable :)"
Nope; totally not astroturfed by a sock puppet of the author!
The intersection of:
- People who understand environment variables in a shell environment and knows what it means to install a Bash function.
- People who have to swap environment variables in the same shell process for whatever weird reason.
- People who don't understand how to use the env utility to run a program in a precisely-determined environment containing only the environment variables they specify.
- People who think it's a good idea to get something from the Apple store to solve a shell programming problem.
Basically, empty set. I see zero PMF (product-market fit) here.
I find the following function amateurish; author should run it through shellcheck. What the funtion does would be completely unnecessary if the Shello GUI maintained the files in a format which the shell could just source; i.e. containing commands like "export var=value".
I won't remark on the shell coding details; the concept here is flawed. To switch from one environment to another, it is not enough to sweep through a file, read in some variables and export them. You also have to delete unwanted variables.
If we switch to environment A, and then B and then back to A, the result should be the same as if we only switched to A, and B never happened.
If we switch back to A, but the namespace is polluted by left-over variables from environment B, that's a fail.
Instead of those files being stored in a shell script format that could simply be sourced, the author provides a badly written shell function to read those files one by one, parse the environment variables and export them. (I'm pasting it below so it is clear what I'm referring to in case it changes.)
The system is flawed because the shell function doesn't remove environment variables; it only adds them.
If we select environment set A, then B and then a A again, it is not the same as just selecting A, as it should be. The environment is polluted by left-over B variables.
In addition, the GUI program has a vanishingly small target audience, consisting possibly of just the author.
Out of the entire population working with shell scripts and environment variables, there has to be a subset which for whatever reason has to juggle among sets of environment variables, and in that subset, those have to be found who would would prefer a platform-specific GUI app from the Apple store to edit the environment variables rather than their favorite text editor.