> The problem with using Direnv is that despite it being a very useful tool, its setup requires investing time and getting over the Nix ecosystem's learning curve.
I'm a bit confused. Direnv is rather simple, is it not.. ?
1. put env variables into .envrc
2. direnv allow
I don't use nix and I don't think I'm over its learning curve. I don't remember investing any time into it..
I'm in the same boat here. I'm very not over the Nix learning curve, so I'm left to conclude that it's actually not easy for some projects.
Last time I tried to use Nix to build a dev environment, it did not go well. I wound up in a Turing tarpit of dependencies, as my Python program needed natively compiled libraries and other things to even get off the ground. I kept having to pull in more of the Nix environment/OS to achieve functional isolation from the parent Ubuntu OS. I also ran into problems with online docs and advice skewing wildly from what the CLI options required of me (probably a skill issue).
And that's when it struck me. Docker has pretty much raised the bar for the developer experience. It can achieve the same amount of isolation for far fewer keystrokes, in less time, and (with docker-compose) has a sharable configuration for others. At the end of the day, a container is just a well isolated process whether it's a webserver or a user shell. And really, that's what you need if you're trying to solve repeatability and isolation. As a bonus, if your software is going to deploy as a container, you're that much closer to emulating the production environment (read: fewer bugs).
I like the Direnv concept and have nothing against Nix or folks trying to share the NixOS experience with others. But from a DevEx perspective, my expectations are set at "as easy or easier than Docker."
But if you are comfortable with Nix you don't need Devbox per se, as you can get by with using Flakes. Here are some examples -- just `git clone` and run `direnv allow` (once), then you are put in the corresponding devShell
There's dedicated direnv configuration for backend and frontend development: checkout `.envrc.backend` and `.envrc.frontend` files. They both use `use flake`, specifying the appropriate devShell argument.
I started messing around with Devbox a few weeks ago and I like it as a faster alternative to toolbox/distrobox containers. I've been adding my environment variables directly into the devbox.json file as normal EXPORT statements. From the article tho, I couldn't grasp what Direnv adds to this. Same Devbox shell, different environment variables per directory?
With direnv you can activate your shell automatically by changing your directory. This is pretty useful if you have multiple projects using devbox, or a monorepo type setup with a few devbox.json files in your subfolders
I try to contribute a lot, which has resulting in me adding .direnv and .envrc to my global gitignores (for other Nix+hm folks[1]). .direnv for obvious reasons, it's a cache, and doesn't frequently show up in project gitignores.
I add .envrc to not only avoid committing it to projects that don't use it, but also because it turns out that it's still pretty environment dependent. There's 100 different ways to skin the dependency problem: Nix, pipenv, nvm, rustup, etc. There's no telling which a contributor prefers to use, so .envrc doesn't belong in git IMHO. What could be committed is something like .envrc-flake (which can then be sourced into .envrc).
As for needing a flake in the repo, I have found a workaround. `use flake` accepts parameters, including the path to the flake. I have a bunch of shells[2] that I can import with e.g. `use flake ~/Nix#rust`.
This is the way. We should make it a standard practice for oss projects that one is able to git clone, direnv allow and build the project.
Regardless of the distro or even OS. An easy thing to say, but hard to execute on actual projects with patched versions of cPython and some obscure in-house build tool.
I would love for an ARCHITECTURE.md to become standard as well... I've definitely skipped contributing to a lot of projects because I'd have to basically have to reverse engineer the project, configuring a dev environment and add a lot of breakpoints to even begin to understand the structure
I wouldn't put an .envrc file in source control. This seems like an anti-pattern.
I think it should be standard practice that you can pull and run a project without configuring environment variables. I agree with that. The defaults should work.
This is not always possible (when you have something that absolutely relies on a third party thing, which you need an environment variable for) - in which case you should be greeted with a helpful error telling you what environment variables you need to set up and why.
It's very hard to define in general what it means to build a project, what are the expected inputs and outputs. Not every build aims to produce the same artifacts, not using the same inputs etc.
What you want could be based on some typical practice in a particular field with a particular project size or structure, but this doesn't transfer well to other fields.
Been using Devbox recently both at work and for personal projects and I can only say good things.
It abstracts away the complexity of nix, defining the dependencies in a simple json with a lock file, the shell starts quite fast and from then on you have everything under your PATH, and it works the same in macOS and Linux.
Also, as a benefit, by tracking the JSON and lockfile, the CI can work with the exact same environment. I highly recommend giving it a try.
Also, as a benefit, by tracking the JSON and lockfile, the CI can work with the exact same environment.
This benefit is also possible under both Nix flakes (inherently) and vanilla Nix. The latter takes mild deliberate effort to not use channels-based import syntax but instead a fetcher with a pinned URL argument.
Actually, the post's solution, besides being built on top of direnv, uses Devbox, which itself is built on top of Nix... https://www.jetify.com/devbox/docs/faq/#how-does-devbox-work So they are saying they are outside the Nix ecosystem when in fact they are in it. It is yet another set of nice scripts on top of Nix.
This seems to be mostly a thin wrapper with a nice interface around nix-shell. Replaces Nix (the language) with this random json format inspired by node package.js. Keeps Nix packages.
My experience of Devbox on Linux has been highly disappointing. I gave it a good go, had it running on my main project from February to May.
In case you hadn't realised, the very concept of having two sets of binary distributions on one machine, vying for superiority and the correct version of glibc... is fraught.
Most of my use was with rails projects, and I can't recommend it.
Coupled with an abstraction that tries to save you from Nix, but almost entirely fails, you end up with a bloated hellscape where every time you load your project it will unnecessarily reinstall your packages and several times an hour it will have forgotten curl exists and so you have to manually reinstall curl (not-so-slowly increasing your /nix folder's size), every week or two a new version of devbox completely changes the workarounds you need to do, and don't try to garbage collect nix or it will delete vital files, and you end up scrubbing it all and starting again.
In python, it overrode the path so I couldn't get it to reliably use the binaries in the venv. Pip and Python were using packages in different places and I couldn't get them to converge for love nor money.
The devbox team were great and really tried to get things working, but in the end I couldn't get it to work with enough stability to properly recommend it to my team, and if I wanted it to half-work for any substantial length of time I had to lock to a version of devbox.
Obviously, ymmv, please do give it a try, it's an impressive project. But my view is that it's trying to do something that is very very hard, and for that you need a very clever solution. And this is a very clever solution, with very clever bugs, and so it's not something I'd recommend jumping into with both feet.
We had a similar experience with devenv. It didn't really prevent us from needing to learn nix, and then we had two things to deal with instead of one. We eventually switched back to just nix.
I do use Nix and direnv for my work Ubuntu machine. The glibc issue rings true, it was crashing my file manager for quite a long time (I suspect for thumbnail generation). I learned to become better at cli file management ;).
Apart from glibc, I have never had issues with two sets of binaries vying for superiority. Nix binaries take preference with my "vanilla" setup. I think that might be Devbox doing something strange with $PATH?
Great project which you can also use as your package manager on your system.
This works nice if your developers have a MacBook with an Arm processor and want to have the build process close to what you do in your ci server which might be a Linux amd64
I created container-shell with a similar goal in mind. It’s super light weight, but does not yet support a package manager. It simply gives you a shell using a specified docker image inside the current directory, isolating both software installs as well as the rest of your filesystem
I think this is my biggest pet peeves when working on different projects. Plus port allocation conflict; if you have multiple docker databases or multiple project using the same default port it's not smooth and obviously changing port is not always an option on legacy projects :/
This looks like a huge overkill to solve the problem that's while real, isn't really so difficult to solve with existing tools... Kind of reminds me of Jucero.
Also, any solution of this kind will inevitably introduce a number of new problems proportionate to the internal complexity of such solution. I.e. this is just asking for a lot of problems, while offering very little in return.
[+] [-] arnorhs|1 year ago|reply
I'm a bit confused. Direnv is rather simple, is it not.. ?
1. put env variables into .envrc 2. direnv allow
I don't use nix and I don't think I'm over its learning curve. I don't remember investing any time into it..
[+] [-] pragma_x|1 year ago|reply
Last time I tried to use Nix to build a dev environment, it did not go well. I wound up in a Turing tarpit of dependencies, as my Python program needed natively compiled libraries and other things to even get off the ground. I kept having to pull in more of the Nix environment/OS to achieve functional isolation from the parent Ubuntu OS. I also ran into problems with online docs and advice skewing wildly from what the CLI options required of me (probably a skill issue).
And that's when it struck me. Docker has pretty much raised the bar for the developer experience. It can achieve the same amount of isolation for far fewer keystrokes, in less time, and (with docker-compose) has a sharable configuration for others. At the end of the day, a container is just a well isolated process whether it's a webserver or a user shell. And really, that's what you need if you're trying to solve repeatability and isolation. As a bonus, if your software is going to deploy as a container, you're that much closer to emulating the production environment (read: fewer bugs).
I like the Direnv concept and have nothing against Nix or folks trying to share the NixOS experience with others. But from a DevEx perspective, my expectations are set at "as easy or easier than Docker."
[+] [-] Flimm|1 year ago|reply
https://devenv.sh
https://direnv.net/
[+] [-] francis-io|1 year ago|reply
[+] [-] llimllib|1 year ago|reply
[+] [-] srid|1 year ago|reply
But if you are comfortable with Nix you don't need Devbox per se, as you can get by with using Flakes. Here are some examples -- just `git clone` and run `direnv allow` (once), then you are put in the corresponding devShell
Haskell: https://github.com/srid/haskell-template
Rust: https://github.com/srid/rust-nix-template
home-manager: https://github.com/juspay/nix-dev-home
Dioxus: https://github.com/srid/dioxus-desktop-template
[+] [-] srid|1 year ago|reply
https://github.com/nammayatri/nammayatri
There's dedicated direnv configuration for backend and frontend development: checkout `.envrc.backend` and `.envrc.frontend` files. They both use `use flake`, specifying the appropriate devShell argument.
[+] [-] discardedrefuse|1 year ago|reply
[+] [-] jljljl|1 year ago|reply
[+] [-] zamalek|1 year ago|reply
I add .envrc to not only avoid committing it to projects that don't use it, but also because it turns out that it's still pretty environment dependent. There's 100 different ways to skin the dependency problem: Nix, pipenv, nvm, rustup, etc. There's no telling which a contributor prefers to use, so .envrc doesn't belong in git IMHO. What could be committed is something like .envrc-flake (which can then be sourced into .envrc).
As for needing a flake in the repo, I have found a workaround. `use flake` accepts parameters, including the path to the flake. I have a bunch of shells[2] that I can import with e.g. `use flake ~/Nix#rust`.
[1]: https://codeberg.org/jcdickinson/nix/src/branch/main/home/co... [2]: https://codeberg.org/jcdickinson/nix/src/branch/main/flake.n...
[+] [-] aerzen|1 year ago|reply
Regardless of the distro or even OS. An easy thing to say, but hard to execute on actual projects with patched versions of cPython and some obscure in-house build tool.
[+] [-] drowsspa|1 year ago|reply
[+] [-] arnorhs|1 year ago|reply
I think it should be standard practice that you can pull and run a project without configuring environment variables. I agree with that. The defaults should work.
This is not always possible (when you have something that absolutely relies on a third party thing, which you need an environment variable for) - in which case you should be greeted with a helpful error telling you what environment variables you need to set up and why.
[+] [-] crabbone|1 year ago|reply
It's very hard to define in general what it means to build a project, what are the expected inputs and outputs. Not every build aims to produce the same artifacts, not using the same inputs etc.
What you want could be based on some typical practice in a particular field with a particular project size or structure, but this doesn't transfer well to other fields.
[+] [-] b112|1 year ago|reply
[+] [-] cquintana92|1 year ago|reply
Also, as a benefit, by tracking the JSON and lockfile, the CI can work with the exact same environment. I highly recommend giving it a try.
[+] [-] mtndew4brkfst|1 year ago|reply
This benefit is also possible under both Nix flakes (inherently) and vanilla Nix. The latter takes mild deliberate effort to not use channels-based import syntax but instead a fetcher with a pinned URL argument.
[+] [-] Fire-Dragon-DoL|1 year ago|reply
[+] [-] Mathnerd314|1 year ago|reply
They mention Nix but I guess they are referring to the use_nix integration built-in to direnv? There is a fairly detailed (but old) comparison in https://github.com/direnv/direnv/wiki/Nix#some-factors-to-co... and in the meantime lorri and nix-direnv are the only ones still maintained. But you aren't limited to Nix when using direnv, for example there is nvm. https://github.com/direnv/direnv/wiki/Node#using-nvm
Actually, the post's solution, besides being built on top of direnv, uses Devbox, which itself is built on top of Nix... https://www.jetify.com/devbox/docs/faq/#how-does-devbox-work So they are saying they are outside the Nix ecosystem when in fact they are in it. It is yet another set of nice scripts on top of Nix.
[+] [-] dudus|1 year ago|reply
[+] [-] a1445c8b|1 year ago|reply
[+] [-] undecisive|1 year ago|reply
In case you hadn't realised, the very concept of having two sets of binary distributions on one machine, vying for superiority and the correct version of glibc... is fraught.
Most of my use was with rails projects, and I can't recommend it.
Coupled with an abstraction that tries to save you from Nix, but almost entirely fails, you end up with a bloated hellscape where every time you load your project it will unnecessarily reinstall your packages and several times an hour it will have forgotten curl exists and so you have to manually reinstall curl (not-so-slowly increasing your /nix folder's size), every week or two a new version of devbox completely changes the workarounds you need to do, and don't try to garbage collect nix or it will delete vital files, and you end up scrubbing it all and starting again.
In python, it overrode the path so I couldn't get it to reliably use the binaries in the venv. Pip and Python were using packages in different places and I couldn't get them to converge for love nor money.
The devbox team were great and really tried to get things working, but in the end I couldn't get it to work with enough stability to properly recommend it to my team, and if I wanted it to half-work for any substantial length of time I had to lock to a version of devbox.
Obviously, ymmv, please do give it a try, it's an impressive project. But my view is that it's trying to do something that is very very hard, and for that you need a very clever solution. And this is a very clever solution, with very clever bugs, and so it's not something I'd recommend jumping into with both feet.
[+] [-] KingMob|1 year ago|reply
[+] [-] zamalek|1 year ago|reply
Apart from glibc, I have never had issues with two sets of binaries vying for superiority. Nix binaries take preference with my "vanilla" setup. I think that might be Devbox doing something strange with $PATH?
[+] [-] weitzj|1 year ago|reply
[+] [-] queil|1 year ago|reply
[+] [-] jbverschoor|1 year ago|reply
https://github.com/jrz/container-shell
[+] [-] h1fra|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] azaras|1 year ago|reply
[+] [-] FireInsight|1 year ago|reply
http://mise.jdx.dev/
Can't manage lower-level deps like dynamic libraries and C compilers, though. I just containerize those.
[+] [-] pprotas|1 year ago|reply
[+] [-] Iridescent_|1 year ago|reply
[+] [-] gregwebs|1 year ago|reply
[+] [-] crabbone|1 year ago|reply
Also, any solution of this kind will inevitably introduce a number of new problems proportionate to the internal complexity of such solution. I.e. this is just asking for a lot of problems, while offering very little in return.
[+] [-] julius-fx|1 year ago|reply
[+] [-] minhdanh72|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]