json_env VS deon

My major pain point was that I had big JSON files inside my .env files. We use Cloud Foundry at work and it uses plenty of these for configuration.

I wrote a small Rust tool called ‘json_env’[0] to read JSON files and supply them as ENV vars to a program. I’m working on it in my free time and eventually want to also replace direnv with it. TOML and YAML support is also planned.

[0] https://github.com/brodo/json_env

I just published my `json_env` crate to homebrew. It's a small CLI app which allows you to start other apps with env variables defined in an `.env.json` file.

When reading the file, the environment variables will be obtained from the URL and populate the environment.

This is what I had in mind when designing the import functionality for deon [1].

Being able to import also makes it easy to have a .base, a .production, a .local setup, and combine them accordingly.

[1] https://github.com/plurid/deon

Hence the second sentence "[b]ut maybe you don't even need to build another Chromium." and then the second paragraph "cost-reducing" billions to millions day-dreaming of a specification-based pixel generator.

Of course, the n-th time is cheaper, easier, faster, case in point: I implemented 'deon', a notation format for structured data [1], using your amazing "Crafting Interpreters" for which I paid nothing since I was reading the web version as you were writing. Never had the chance to say thank you, somewhere in my drafts there is an email of appreciation: reading your book and applying it chapter by chapter, crafting a final, useful artifact, has been a beautiful experience, thank you very much, for all your writing, since I am a longtime reader of your technical and otherwise texts.

[1] https://github.com/plurid/deon