Allowing custom configuration to $HOME/.config/direnv/direnvrc

[vendion]

I am wanting to setup a few recipes/layouts that are in the direnv wiki such as per project postgres data and daemonize, it seems that putting this in $HOME/.config/direnv/direnvrc makes sense, but it semes that file already gets created and sources in data needed for nix-direnv from the nix store.

Failing that I tried to add the custom functions to my projects .envrc file, but it doesn't seems to work as I can't call the functions. Even if I could I would have to copy these snippits to all .envrc files rather than being able to just define it once.

[bbenne10]

1. functions and aliases are unsupported as "exportables" by direnv - they're not shell portable and may contain arbitrary shell code (which can't be automatically translated with out massive effort), so...no - you can't do that (and it isn't our fault). I don't know how one is expected to use daemonize in particular in a "raw" direnv use case, but you may also explore shellHook to get that working (The postgres snippet is clever and should probably work fine).
2. We don't put anything in ~/.config/direnv/direnvrc. That's (probably) home-manager's fault. Use programs.direnv.direnvrcExtra on NixOS or programs.direnv.stdlib if using home-manager to put extra things into that file.

[bbenne10]

Upon re-reading the daemonize code, I suspect the expectation is that this function is to be called inside your .envrc. Direnv does not support using these functions "interactively" (after the direnv run has completed). You'd need to make the daemonize function available to your direnv shell (either in .envrc or ~/.config/direnv/direnvrc) and then call daemonize foo_groobler in your .envrc.

That being said: I don't think that's a good idea - you can very easily end up with abandoned processes from old projects hanging around after you cd away. If you want this, maybe look at devenv?

[vendion]

Thanks for your response and explanation. I have tried using the `shellHook`, but if I try to start up Postgres or even MySQL/MariaDB then direnv hangs, probably has something to do with everything running in a subshell thus even though the server demonizes itself the subshell never exits. Ideally what I'm trying to do is set things up so when I `cd` into a project directory the correct DB automatically starts (if possible). I guess in the meantime I'll try using the `shellHook` to initialize the DB if needed and add functions in my shell config to actually start the DB.

…

On Thu, Apr 11, 2024, 8:16 AM Bryan Bennett ***@***.***> wrote: Upon re-reading the daemonize code, I suspect the expectation is that this function is to be called *inside your .envrc*. Direnv does not support using these functions "interactively" (after the direnv run has completed). You'd need to make the daemonize function available to your direnv shell (either in .envrc or ~/.config/direnv/direnvrc) and then call daemonize foo_groobler in your .envrc. That being said: I don't think that's a good idea - you can very easily end up with abandoned processes from old projects hanging around after you cd away. If you want this, maybe look at devenv <https://devenv.sh/>? — Reply to this email directly, view it on GitHub <#484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDM6UMEMMSH5XKNKBZUMTY4Z5KPAVCNFSM6AAAAABGBW6QK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBZGU3DMNJQGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bbenne10]

shellHook is not for long running processes. You will run into issues there. I expected the daemonize call to work, but I'm disinclined to chase down why it doesn't. Again: Have a look at devenv. This workflow is what it is designed for. You're reinventing the wheel (and frankly doing so poorly and with less consideration than what Domen has put into devenv).

(OR use sqlite for development and maria for deployment, but that's harder and I know it's difficult to switch once you have the approach solidified)