[HN Gopher] Show HN: Envelope - A modern environment variable cl...
___________________________________________________________________
Show HN: Envelope - A modern environment variable cli tool
Hey HN! I've built this cli tool to manage env variables of a
project, but mostly for fun and to try out Rust and the clap crate.
I had this idea when I made a big mistake and broke some production
stuff because I had a very messy .env file laying around in my
project. I was implementing new features for one of my projects
and in my .env file I had the test database url commented out and
the production one was not. Long story short, I applied migrations
to the production database instead of my local test one and broke a
lot of production APIs :') I wanted a tool that could easily help
me spot these issues before something bad happened, and so I built
envelope for that reason. Instead of a \\.env(\\..+)? file, I now
use this tool to add variables to different configurations: dev,
prod etc. and I feed them to the program I am executing on a one
liner. $ envelope init $ envelope add dev
db_url localhost:5432/postgres $ envelope add dev db_username
username $ envelope add dev db_pwd pwd $ export
$(envelope list dev) $ ./run.sh This way I am
explicitly exporting the dev environment without relying on the
fact that everything is in order in my .env file (another approach
would be to have a .env.dev file) A very useful feature that I use
quite a lot is the `check` command which is going to tell you which
environment you have currently active $ export
$(envelope list dev) $ envelope check > dev I
don't think this tool is going to be useful to anybody, but I
wanted to share this with you in case there is someone that can
make good use of it or find particular scenarios where this could
be used instead of .env files, either way I had a lot of fun
building it
Author : mattrighetti
Score : 63 points
Date : 2024-06-22 12:39 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cranberryturkey wrote:
| how do I install the damn thing??
| mattrighetti wrote:
| I'll copy the answer to a similar question in the issues:
|
| > I used to have a `brew tap` for it but I've removed it
| temporarily. To install it you can download the binary file in
| the latest release[0] and move it to your `/usr/local/bin`
| folder (on macOS this is what I'd do) or any other folder that
| is in your `$PATH`.
|
| [0]: https://github.com/mattrighetti/envelope/releases/latest
| cranberryturkey wrote:
| Can we get an arch package?
| i4k wrote:
| yep, do it!
| breck wrote:
| I like it.
|
| Env variables should be a solved problem but no one has made the
| simplest general solution yet. Seems like you are on track.
|
| One suggestion: no need to use SQLite. Just develop a simple (and
| _lasting_), plain text DSL and save to a file.
|
| Here's one I made using your example.
|
| https://sdk.scroll.pub/designer/#parsers%0A%20valueCell%0A%2...
|
| I'm happy to chat more to nail that design if that would be
| helpful.
| gtirloni wrote:
| I was thinking the same because how do you version control
| SQLite in git?
| skeledrew wrote:
| I don't think you want your secrets committed...
| mattrighetti wrote:
| > how do you version control SQLite in git?
|
| Interesting article just about that [0]
|
| [0]: https://garrit.xyz/posts/2023-11-01-tracking-sqlite-
| database...
| bloopernova wrote:
| A parser playground? Wow that is very cool.
| breck wrote:
| Thanks. It is not "great" yet but it is pretty good and
| reliable and has served me well for many years.
|
| At some point I may clean up the code so that it can really
| shine.
|
| Higher priority though is getting support for this Parsers
| language in Sublime and VS Code.
| cbarrick wrote:
| Seems like .env is already an ideal DSL here. It's just a
| subset of shell. Easy to parse and index too.
| breck wrote:
| It's close to ideal, but not ideal.
| eikenberry wrote:
| > Env variables should be a solved problem
|
| I think the main problem is that this problem is 99% solved by
| the shell alone. Shells are very versatile and it is quite easy
| to setup different environments using your shell. I'd bet that
| the crossover of people good at manipulating environments on
| workstations and people good with shells is pretty big. That
| is, the people with good domain knowledge have little
| motivation to write tools to address this.
| bloopernova wrote:
| Interesting!
|
| Have you looked at mise-en-place at all? It's written in rust
| too, and might have some cool ideas to use: https://mise.jdx.dev/
| leetrout wrote:
| A word of caution - this is a way to leak your secrets through
| your shell history: $ envelope add dev db_pwd pwd
|
| There are settings such that a command that starts with a space
| will not be saved in the history which would help here but I
| would be very careful about how you use this.
| mattrighetti wrote:
| Mine was a bad example :) the command also lets you input stuff
| from stdin for that very case
| tomwphillips wrote:
| Of all the adjectives to use, why "modern"?
|
| Very common these days. I don't get it.
| RadiozRadioz wrote:
| Maybe it's a synonym for "Rust/Go instead of C/C++"
| keb_ wrote:
| Same, except I take issue with the word "tool." Like a program?
| A library? A screwdriver? Very ambiguous. Very common these
| days as well. I don't get it.
| looperhacks wrote:
| It's explicitly called a "cli tool", not very ambiguous imo
| bityard wrote:
| I've noticed it's something a lot of Rust programs describe
| themselves as. Implying that software written in other
| programming languages is somehow vintage or obsolete, I guess.
| peter_l_downs wrote:
| I think a lot of new entrants to previously-well-explored
| spaces tend to label themselves as "modern" in order to signify
| that there is something new about their approach.
|
| For instance, I have a migrations library that I descibre as
| "modern" because it is designed for a continuous deployment
| environment where you're automatically running migrations on
| container startup -- there are tons of existing popular
| migrations libraries, but none of them work this way because
| they were written in the era that you'd manually run sql
| commands in prod. I say "modern" so that if anyone finds my
| library, they realize that it was created recently based on
| more recent dev/ops trends.
|
| Maybe I should drop the "modern"? I do see a lot of people
| describe their code as "minimal" or "clean", which is pretty
| meaningless to me, so I get that "modern" could come across
| that way as well.
| skeledrew wrote:
| Another issue with using such relative qualifiers IMO is that
| they become meaningless over time, as the namespace becomes
| polluted as every few years something addressing some problem
| with a potentially different approach is given a similar
| qualifier.
| rpigab wrote:
| Ripgrep is recent and written in Rust, but it does not describe
| itself as modern, even if some apects of it are.
|
| Its interface is designed to be an almost drop-in replacement
| of grep, which makes it "old style".
|
| I think software can be old style, modern, or neutral. Most
| software written today aims for modern, it seems logical.
| Kwpolska wrote:
| The docs don't make it very obvious how are the environment
| variables actually applied. And I think .env files are much
| easier to manage and share. `envelope check` could be replaced
| with a CURRENT_ENV environment variable in an .env file. I can't
| see how it would help avoid environment confusion more than
| $CURRENT_ENV displayed in your prompt would. (Or even better, not
| having production credentials on developers' machines...)
| mattrighetti wrote:
| > The docs don't make it very obvious how are the environment
| variables actually applied.
|
| Actually, they are not applied. This is a tool that helps you
| manage them, you can see it as a replacement of .env files.
|
| > `envelope check` could be replaced with a CURRENT_ENV
| environment variable in an .env file
|
| Can you elaborate more on this? I've never used that tbh and
| I'm interested
| SeriousM wrote:
| envkey.com is also distributing environment variables
| twerkmonsta wrote:
| you probably don't need sql
| mattrighetti wrote:
| Agreed, sqlite is definitely overkill for this kind of task but
| it's also lightweight and fast, so why not?
| stephenr wrote:
| > I had the test database url commented out and the production
| one was not.
|
| I feel like this is a giant red flag. Why on earth is your
| production database accessible from anywhere (ie your PC) without
| some kind of extra layer of security like a VPN or SSH tunnel?
| mattrighetti wrote:
| The production database that I'm talking about is a Postgres
| instance that is only available to me in my house for my side
| projects, it contains random stuff that can be queried through
| APIs that me and my family use with an app that works only when
| we are connected to our home LAN. Therefore I'm not paying as
| much attention when I do stuff with it as I would on a database
| that thousands of users rely on. Still, it sucks because it
| took quite some time to bring it back to a working state.
| Lesson learned
| another-dave wrote:
| > This way I am explicitly exporting the dev environment without
| relying on the fact that everything is in order in my .env file
| (another approach would be to have a .env.dev file)
|
| What did you find lacking with the .env.dev approach? (Or if some
| tool doesn't support .env.dev could always symlink .env -
| .env.dev)
| mattrighetti wrote:
| The cons of that is that sometime I'd end up with 3 different
| files for different scenarios and in one particular case my
| tool only cared about the .env file, so I had to do a lot of
| `mv .env.dev .env` every time I had to switch to another env
| configuration.
| skeledrew wrote:
| Hmm I fairly recently started saving variables which tend to be
| shared among multiple projects in a central location, grouped in
| sh files and sourcing as needed. This gives me an idea to improve
| that flow...
| globular-toast wrote:
| Seems neat, but direnv can do more despite this claiming to be
| "modern".
___________________________________________________________________
(page generated 2024-06-22 23:01 UTC)