Can someone explain to me the advantage of using Nix over containers? What do they offer that are not provided with using docker or other container platform.
Nix has support for containers, and personally I think they are a beauty. Like the rest of the system. The advantage of Nix is similar thought: The first green build of any revision is cached and kept as "that revisions build" forever. Similar like a container.
Devenv.sh: Fast and reproducible developer environments using Nix
51–60 of 171 posts
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#52Can someone explain to me the advantage of using Nix over containers? What do they offer that are not provided with using docker or other container platform.
If I’m not mistaken, Nix uses cgroups as well on non-NixOS systems, so it is basically containers. You’re probably thinking about docker as a whole, in which Nix is effectively an alternative package manager/distribution system for containers.
Installing and using Nix packages doesn't generally involve any sandboxing or containerization features. But on Linux, there are some exceptions. A few proprietary packages use something called an FHSUserEnv, which leverages user namespaces to simulate an FHS-compatible environment. Additionally, Nix (through one of the new, experimental commands as well as an older third-party tool that inspired it) can also bundle any Nix package into a containerized package which can be run without Nix. I think those bundles, if you choose to create them, also use some container-y Linux features.
Anyway devenv.sh isn't built on anything container-y in Nix.
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#53Earlier quoted context omitted.
You don’t want to deploy your development tool chain to your production environment, ergo, you want a development environment.
In the JS world it's common to have hot-reloading development servers, whereas the production environment does not do that. And with the rise of TS, transpilation and bundling are also a thing on the backend, not just for shipping web assets. Once the bundle is done, all your production server needs is `index.js` and `node`, not `tsc`, `webpack` or whatever else you're using.
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#54Can someone explain to me the advantage of using Nix over containers? What do they offer that are not provided with using docker or other container platform.
Containers are way too slow, and take too much space (they don’t share dependencies). Also doesn’t necessarily play well with tools AND is hard to setup for dev environments (what do you mount?)
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#55this, devbox, and others seem to be alternatives to `nix-env shell` or the flake-based `nix develop`. spurred i think by a desire for better UX. these are excellent for any project off-the-ground enough that you’ve run `git init` or created a repo. the adjacent area i’m struggling with is the “i want to write a tiny program to verify some conjecture, and i’ll probably throw it away an hour from now”. think codegolf c…
> I’d love a tool where i can just `cd /tmp/my-hourlong-project` and then `devenv python` to get a python shell that’ll have everything i often use (and probably more) There's a dozen projects that do this. But it would honestly take you as much time to write a shell script to do it as use some other project to do it. Like, seriously: #!/usr/bin/env sh set -eu [ "${DEBUG:-0}" = "1" ] && set -x MY_TEMPLATE="${MY_TEMPL…
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#56Hi all, I'm the author of https://devenv.sh , https://cachix.org and https://nix.dev . I've been part of the Nix community for more than 10 years and in the last 4 years focused on making it documented, simple and accessible for any developer. After building Cachix (where you can store any software binaries with a few steps) we realized that there needs to be an intuitive interface for crafting developer environments…
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#57I think it is an overkill to have your dev environment different from your deploy environments. This would mean you maintain dev environments separately than deploy environments. It would mean you are debugging something other than you are testing and deploying. About reproducibility, unless nix promises to fix all upstreams (apt, pypi ??), I don't see how it can fix reproducibility on the client side only.
Concrete example, dev environment with nix but production is Dockerfile with apt getting packages?
Thoughts?
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#58Hi all, I'm the author of https://devenv.sh , https://cachix.org and https://nix.dev . I've been part of the Nix community for more than 10 years and in the last 4 years focused on making it documented, simple and accessible for any developer. After building Cachix (where you can store any software binaries with a few steps) we realized that there needs to be an intuitive interface for crafting developer environments…
Do you use NixOS? I've found it a little too clunky for my taste, as a Gentoo Linux user. But maybe Nix is still worthwhile for me as a standalone tool.
I've used it as my daily driver for the past year so maybe I can help elaborate too.
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#59I avoid "developer environments" because they are different from production environments and that leads to bugs that don't show until the application is in production. "But it worked in development" problems waste a lot of time. Putting "developer environment" in the name of this tool perpetuates bad practices. Any tool that constructs environments for applications should be general enough to handle both production a…
I, at the very least, completely disagree with you on this specific point as this tool is using Nix.
Re: Devenv.sh: Fast and reproducible developer environments using Nix
#60Earlier quoted context omitted.
The latest version of devbox allows pinning the sha of the nixpkgs repository to whatever you want. We don't yet allow pinning on a per-package basis within nixpkgs, but we're working on that.
> We don't yet allow pinning on a per-package basis within nixpkgs, but we're working on that. Where can I view that work? That's a feature the whole Nix ecosystem could benefit from. Is there an RFC for Nixpkgs to change the policy on versioning, or is this an effort to rig up some kind of frontend for an index that lets you pull package recipes from different versions of Nixpkgs?
For a lot of the most important ones, though, nixpkgs already maintains multiple recent versions, though— fifteen boosts in there right now: https://search.nixos.org/packages?channel=unstable&from=0&si...