Introducing lorri, your project's nix-env

Announcements
1

Hello everyone!

I’m really excited to announce with Profpatsch the public release of lorri, a nix-shell replacement for project development. lorri is based around fast direnv integration for robust CLI and editor integration.

lorri solves several painpoints of using nix-shells for project development like slow evaluation times and nix-shell garbage collection.

Profpatsch and I have written up some of the motivation and improvements Lorri makes on Tweag’s blog: https://www.tweag.io/posts/2019-03-28-introducing-lorri.html. There are also installation instructions and a tutorial at https://github.com/target/lorri.

Profpatsch and I have been building it at Tweag for Target’s Data Science and Optimisation team (who by the way is hiring for their team which uses neat tools you’ll probably like.)

lorri supports NixOS of course, Linux, and macOS. Give it a try!

7 Likes
2

Any advantages over using Nix · direnv/direnv Wiki · GitHub?

3

As the page says:

Out of the box, however, direnv’s Nix integration is slow – continuously, unnecessarily evaluating Nix expressions. In some editors the expressions are re-evaluated on every file switch. This is painful, especially if the evaluation takes even half a second!

lorri’s direnv integration doesn’t ever call Nix. Instead, the integration always selects the last cached evaluation, ensuring a lightning-fast editor and shell experience.

When entering a project directory your tools just appear, ready to use.

4

I did read the whole thing but with the “persistent cache” direnv is pretty fast. I’m wondering if lorri is even faster and if there’s other advantages before I switch. I’m guessing it’s simpler to use. That could be worth it.

5

The difference is that it’ll use the previous derivation while at the same time building the new one in the background. That means you don’t have to wait for nix to finish before doing stuff in your project.

I’ve been using the persistent cache direnv for a few months now myself, and it’s pretty close actually, but doesn’t handle well when you use stuff like import <nixpkgs> and update your channels regularly.

There’s the tradeoff that lorri will require the lorri watch process to run, I wrote Avoid having to run `lorri watch` yourself · Issue #2 · target/lorri · GitHub so at least it’s as automatic as the persistent cache approach.

Also i don’t have to keep deleting .direnv dirs to refresh my shell (at least that’s my hope, been literally using it for about an hour now).

2 Likes
6

This looks very nice and a welcome improvement over direnv + nix-shell + persistent cache! I haven’t been able to dig deeper yet, but on on my MacBook with Mojave, lorri watch does not really seem to work. The environment is only updated when I terminate lorri watch and start it again.

I’ll try to do some more digging (when time permits) and file an issue.

7

Do you use import <nixpkgs> {} ? Update your channels and … Oops! Your Nix shell is stale! Opening a new nix-shell means downloading all new dependencies before you’re able to get back to work.

I ended up with another (perhaps more simple) solution - to have an option to capture <nixpkgs> (including config, overlays and localSystem (which includes system and platform, for platform.gcc.arch)) into the produced system closure, so the preserved read-only snapshots could be used instead of <nixpkgs>:

    nix.nixPath = [
      "nixpkgs-booted=/run/booted-system/nixpkgs"
      "nixpkgs-current=/run/current-system/nixpkgs"
      "nixpkgs-next=/nix/var/nix/profiles/system/nixpkgs"
    ];

import <nixpkgs-current> {} does not allow to override overlays or config or platform (<nixpkgs-current/pkgs/top-level/impure.nix> is patched and has the captured values hardcoded), so the development pipeline and the test-driver always reuse the current system binaries, even if the <nixpkgs>'s content is changed, upgraded or lost (for example by git pull)

5 Likes