you need to initialize quickenv per-project using quickenv reload, and rerun that command everytime the .envrc changes.
These parts are less attractive to me. I like direnv in the context of a team project where I can know that once direnv is configured, everyone will always have up-to-date environment variables. If people will need to run quickenv reload after the file changes then it will get missed and people (including myself) will likely end up using wrong env vars.
yeah, I know. for the first version I chose to forego such hard problems as cache invalidation to keep my goals of making quickenv significantly faster than direnv. I see too many people at my job opting out of our direnv setup entirely because it’s too slow, and that seemed even worse than using outdated envvars to me. At least as long as there is an obvious “fix-it-button” such as quickenv reload that seemed good enough to me.
direnv adds to your shell’s PROMPT_COMMAND to execute a file called .envrc everytime you cd into a directory containing such a file. it doesn’t cache the result, and every time you create a new shell session or cd in/out of your project, you have to wait until that file completes executing. in the projects i’m working on, that .envrc does a ton of sanity checks that take a few hundred milliseconds to execute. too laggy for my taste.
direnv doesn’t have a cache, mainly because cache invalidation is hard. quickenv does have a cache, but doesn’t bother with cache invalidation (you just have to run reload or it’s stale). that’s what makes quickenv faster: it accepts a potentially stale environment over perf slowdown.
Thanks for this. A great readme which leaves me with no questions.
Instead I have a question for the community more generally: do you ever need to use this class of tool if you keep multiple shell tabs open? I know I move between directories only when related to the same “theme”. With multiple shell tabs I can keep my env as I need for that task, and if I need other envs I use another tab; or if I’m on an ssh session I use multiple screen sessions.
Not a challenge to the community, rather I’m interested in learning about other people’s workflows.
So, I use tmux, and I do use windows/panes. it’s not that I switch a single bash session between projects a lot. it’s more that I create and destroy a large amount of sessions per-project, i.e. when I decide to launch tests next to my open vim buffer I usually find myself in a situation where I don’t have an “unoccupied” shell to do so.
I could probably configure tmux to inherit environment variables from the currently active pane (I already inherit the working directory), but I feel like that would come with too many unintended consequences.
The reason we use direnv at work is quite different. We have a team dedicated to maintaining “the” developer environment. Meaning that, if you don’t want to figure out how to setup the devenv yourself, you can install direnv, check out a repo, run direnv allow, and (at least ideally), by the time the script is done, running tests and linters should “just work”, and will continue to do so as the repo changes. That’s a good thing to have if you don’t want to onboard your frontend devs to the hellscape that is Python package management, or vice-versa with backend devs as well (yet both groups want to run the entire application end-to-end).
As a result you end up with two groups of people: 1) those who value automated setup over responsiveness of their terminal 2) those who value terminal responsiveness over automated setup
Yes. Every time I restart a workstation, I need to reopen my shell tabs. My memory is poor and I don’t remember how to configure tools for each project. direnv lets me forget how each project is set up.
I, too, keep tabs open and don’t find the ~directory-based approach very enticing. I do, however, have like a little ~project-based system where I give each tab a “purpose” that I can attach extra shell init to.
For me, the automatic shell environment tools are invaluable. Between personal and work projects, I usually have 10-30 different project environments I may need to consider at any one time, and I do jump between them in shells pretty often, especially using z.
A second use case for me is that direnv ties right into Emacs, so in each buffer I get that project’s environment automatically. I switch buffers / projects all the time.
These parts are less attractive to me. I like direnv in the context of a team project where I can know that once direnv is configured, everyone will always have up-to-date environment variables. If people will need to run
quickenvreload after the file changes then it will get missed and people (including myself) will likely end up using wrong env vars.yeah, I know. for the first version I chose to forego such hard problems as cache invalidation to keep my goals of making quickenv significantly faster than direnv. I see too many people at my job opting out of our direnv setup entirely because it’s too slow, and that seemed even worse than using outdated envvars to me. At least as long as there is an obvious “fix-it-button” such as
quickenv reloadthat seemed good enough to me.I’m not familiar with direnv but I’ve heard of it and know what it’s for. How slow is it and why?
direnv adds to your shell’s
PROMPT_COMMANDto execute a file called.envrceverytime youcdinto a directory containing such a file. it doesn’t cache the result, and every time you create a new shell session or cd in/out of your project, you have to wait until that file completes executing. in the projects i’m working on, that.envrcdoes a ton of sanity checks that take a few hundred milliseconds to execute. too laggy for my taste.direnv doesn’t have a cache, mainly because cache invalidation is hard. quickenv does have a cache, but doesn’t bother with cache invalidation (you just have to run
reloador it’s stale). that’s what makes quickenv faster: it accepts a potentially stale environment over perf slowdown.I filed an issue because I eventually want to make cache invalidation a thing: https://github.com/untitaker/quickenv/issues/6 – would be interested in your feedback there
The combination of direnv and nix has been just blissful
Wrote this over the past few days and am looking for some feedback.
Not sure what to tag it. I think a
devtooling/devenvtag could make sense. Almost was tempted to tag itvcsanddevops.Thanks for this. A great readme which leaves me with no questions.
Instead I have a question for the community more generally: do you ever need to use this class of tool if you keep multiple shell tabs open? I know I move between directories only when related to the same “theme”. With multiple shell tabs I can keep my env as I need for that task, and if I need other envs I use another tab; or if I’m on an ssh session I use multiple screen sessions.
Not a challenge to the community, rather I’m interested in learning about other people’s workflows.
So, I use tmux, and I do use windows/panes. it’s not that I switch a single bash session between projects a lot. it’s more that I create and destroy a large amount of sessions per-project, i.e. when I decide to launch tests next to my open vim buffer I usually find myself in a situation where I don’t have an “unoccupied” shell to do so.
I could probably configure tmux to inherit environment variables from the currently active pane (I already inherit the working directory), but I feel like that would come with too many unintended consequences.
The reason we use direnv at work is quite different. We have a team dedicated to maintaining “the” developer environment. Meaning that, if you don’t want to figure out how to setup the devenv yourself, you can install direnv, check out a repo, run
direnv allow, and (at least ideally), by the time the script is done, running tests and linters should “just work”, and will continue to do so as the repo changes. That’s a good thing to have if you don’t want to onboard your frontend devs to the hellscape that is Python package management, or vice-versa with backend devs as well (yet both groups want to run the entire application end-to-end).As a result you end up with two groups of people: 1) those who value automated setup over responsiveness of their terminal 2) those who value terminal responsiveness over automated setup
Yes. Every time I restart a workstation, I need to reopen my shell tabs. My memory is poor and I don’t remember how to configure tools for each project.
direnvlets me forget how each project is set up.I, too, keep tabs open and don’t find the ~directory-based approach very enticing. I do, however, have like a little ~project-based system where I give each tab a “purpose” that I can attach extra shell init to.
For me, the automatic shell environment tools are invaluable. Between personal and work projects, I usually have 10-30 different project environments I may need to consider at any one time, and I do jump between them in shells pretty often, especially using
z.A second use case for me is that
direnvties right into Emacs, so in each buffer I get that project’s environment automatically. I switch buffers / projects all the time.Coincidentally, I just wrote something similar for fish. What timing!
(It’s far less documented than this, of course.)