nix.dev

nix.dev copied to clipboard

Add section for direnv that links readers to the nix-community implementation as it's: 1 - faster due to caching of the environment 2 - creates a gcroots

Open question: Why isn't this implementation upstreamed to the default direnv implementation ?

Ugh CLA are a bit annoying to get sign-off from my employer.

Two things:

1. Tutorials are supposed to teach the recommended way and not offer a split situation in the middle. If there's a better way, we rewrite the tutorials. If there's something to learn on top, it can be in the Going Forward section.

2. nix-direnv has a problem that it only reloads when shell.nix/default.nix changes, which is often not the only Nix source. That leads to wrong expectations so I'd rather teach users the correct way and what to expect than use something that works some of the time.

Your feedback is valid although confusing for using direnv by itself; wouldn't the native integration suffer from the same criticism with respect to reloading?

opinion: The caching of the output of the generation + gc roots though is quite a productivity win. So much so that there are competing products https://github.com/target/lorri just to solve the same issue. Having the tutorial still focused on direnv but offer jumping off points in a Going Forward section seems appropriate.

Sounds like you want to close the PR.

There are quite a few options as you mentioned (direnv-nix, lorri, etc.) but none of them reliably solve the problem (in my experience) so I'd rather leave that problem to an explicit user action than to sometimes work and sometimes not.

I'm fine if Going Forward section would have bullet point explaining that lorri and direnv-nix solve this but with caveat that not always reliably.

How about just describing the flake support of nix-direnv? With flakes in most project I have seen so far it was sufficient to just take flake.nix and flake.lock into account. Having external files is still possible but I would call this advanced usage.

Otherwise a link in the going forward section could be dropped that just links to the direnv wiki page about nix, where people can pick their favorite implementation.

How reliable is nix-direnv, any drawbacks?

I use it for all my projects. I don't even notice any of the problems you've hinted at.

I love it's simplicity. I don't understand why lorri needs a daemon...so complex.

On Thu, Sep 30, 2021, 12:39 PM Domen Kožar @.***> wrote:

How reliable is nix-direnv, any drawbacks?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nix-dot-dev/nix.dev/pull/83#issuecomment-931609521, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAETXDXSJXE5HAYCIKKMVRTUES4GPANCNFSM4PCXPCYQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I'll give it a try, should have done that before I expressed my concerns :)

+1 for adding nix-direnv to the tutorial, I've been using it for quite a while and recommend it in all our internal docs. Like so:

Speed convenience - nix-direnv

With direnv configured, every time you open a new terminal and cd into kai-app project, you have to wait a few seconds for Nix to do its magic and prepare a shell for you. This gets a bit annoying after some time.

Additionally, since nix-shell environments are temporary by default, any time you run nix-garbage-collect, your project derivations will get removed, so you will have to wait longer the next time you cd into kai-app since Nix will have to build things again.

Both of these problems can be overcome by using the nix-direnv plugin for direnv. Follow install instructions on https://github.com/nix-community/nix-direnv/, or see how @zupo has done it on his MacOS: https://github.com/zupo/dotfiles/commit/b77595522ac34bb9819da8967d96a72770e6a58e

Here's an example of how the first cd takes 3 seconds, and the following one just 0.06 seconds!

~$ time (cd kai-app)
direnv: loading ~/work/kai-app/.envrc
direnv: using nix
symlinking node_modules ...
direnv: eval /Users/zupo/work/kai-app/.direnv/cache-unknown
direnv: renewed cache and derivation link
direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +DETERMINISTIC_BUILD +FRONTEND +HOST_PATH +IN_NIX_SHELL +LD +LD_DYLD_PATH +MACOSX_DEPLOYMENT_TARGET +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_x86_64_apple_darwin_TARGET_HOST +NIX_BUILD_CORES +NIX_BUILD_DONT_SET_RPATH +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_x86_64_apple_darwin_TARGET_HOST +NIX_CFLAGS_COMPILE +NIX_COREFOUNDATION_RPATH +NIX_CXXSTDLIB_COMPILE +NIX_CXXSTDLIB_LINK +NIX_DONT_SET_RPATH +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_IGNORE_LD_THROUGH_GCC +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_NO_SELF_RPATH +NIX_STORE +NM +PATH_LOCALE +PYTHONHASHSEED +PYTHONNOUSERSITE +PYTHONPATH +RANLIB +SDKROOT +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +TEMP +TEMPDIR +TMP +__ETC_PROFILE_SOURCED +__darwinAllowLocalNetworking +__impureHostDeps +__propagatedImpureHostDeps +__propagatedSandboxProfile +__sandboxProfile +buildInputs +builder +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +gl_cv_func_getcwd_abort_bug +name +nativeBuildInputs +nobuildPhase +out +outputs +patches +phases +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH
( cd kai-app; )  2.93s user 0.66s system 97% cpu 3.676 total


~$ time (cd kai-app)
direnv: loading ~/work/kai-app/.envrc
direnv: using nix
direnv: using cached derivation
direnv: eval /Users/zupo/work/kai-app/.direnv/cache-unknown
direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +DETERMINISTIC_BUILD +FRONTEND +HOST_PATH +IN_NIX_SHELL +LD +LD_DYLD_PATH +MACOSX_DEPLOYMENT_TARGET +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_x86_64_apple_darwin_TARGET_HOST +NIX_BUILD_CORES +NIX_BUILD_DONT_SET_RPATH +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_x86_64_apple_darwin_TARGET_HOST +NIX_CFLAGS_COMPILE +NIX_COREFOUNDATION_RPATH +NIX_CXXSTDLIB_COMPILE +NIX_CXXSTDLIB_LINK +NIX_DONT_SET_RPATH +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_IGNORE_LD_THROUGH_GCC +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_NO_SELF_RPATH +NIX_STORE +NM +PATH_LOCALE +PYTHONHASHSEED +PYTHONNOUSERSITE +PYTHONPATH +RANLIB +SDKROOT +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +TEMP +TEMPDIR +TMP +__ETC_PROFILE_SOURCED +__darwinAllowLocalNetworking +__impureHostDeps +__propagatedImpureHostDeps +__propagatedSandboxProfile +__sandboxProfile +buildInputs +builder +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +gl_cv_func_getcwd_abort_bug +name +nativeBuildInputs +nobuildPhase +out +outputs +patches +phases +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH
( cd kai-app; )  0.06s user 0.12s system 95% cpu 0.192 total

This has been open for a while. Before asking @fzakaria to resolve the merge conflict it would be good to know if this will be merged.

@Mic92 @domenkozar

@domenkozar now also should know better what it does because he merged a variant of the code into devenv.

Using nix-direnv sounds good to me instead of the default.

Agreed, this should be recommended as the default instead.

Closing as #597 addresses this