21 ms·

Devenv.sh: Fast and reproducible developer environments using Nix

382 points by frankpf 4y ago

cphoover 4y ago
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.
- judge2020 4y ago
  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.
  - callahad 4y ago
    I believe you are mistaken; Nix has no intrinsic connection to cgroups / containers.
    - ghostwriter 4y ago
      how does it enforce FS and network isolation?
      - InvaderFizz 4y ago
        It doesn't. Nix is basically a whole load of compiled dependencies pathed to /nix/hash/dependency So you can have things that would ordinarily be dependency hell running side by side because foo that requires bar6 is compiled against that, and baz that requires bar7 is linked against that. Both versions of bar are present in the nix structure, on a specific path that the software is compiled against.
        pxc 4y ago
        To summarize this in a metaphor: Nix 'isolates' packages by ensuring that they do not know where to look for each other, rather than ensuring that they cannot possibly see each other. In addition to the example given by the parent poster, here are some other steps taken towards that end in the Nix ecosystem: Nix-built programs look for their libs, they don't see libs other than what they were built with because each package has its own little FHS-shaped tree, which it thinks of in the way a 'normal' package might think of as 'the system'— that thing which has a `/usr/lib` in which to find libraries and a `/etc` in which to find config files and a `/usr/share` in which to find assets, etc. In addition to linking against hardcoded full paths to dependencies, outlined above, maintainers also take steps to ensure that, e.g., external programs referenced in shell scripts in a Nix package also refer to full paths into the Nix store.
        ghostwriter 4y ago
        How do you mean it doesn't if the manual itself says that: "In addition, on Linux, builds run in private PID, mount, network, IPC and UTS namespaces to isolate them from other processes in the system"? https://nixos.org/manual/nix/stable/command-ref/conf-file.html#conf-sandbox https://nixos.org/manual/nix/stable/command-ref/conf-file.ht...
        callahad 4y ago
        "Builds" is the operative word there: that specific isolation is optional and only applies during compilation.
  - mikepurvis 4y ago
    It uses some of that stuff to isolate its background build sandbox, but none of it affects a normal nix subshell.
  - pxc 4y ago
    Nix has configurable support for build sandboxing. On Linux, that sandboxing is enabled by default, but builds and installs and everything work fine without it. 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.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- carlmr 4y ago
  One thing is perfect caching. Each package is cached in its own folder, so if you exchange one package you don't have to rebuild the rest of the image. Also you can have multiple versions of the package cached. Also all your environments benefit from the cache, since each "layer" is independent. Docker's layer based caching is very limiting for larger images. With Nix you spend basically no time on incremental builds outside of the time for the one package you changed.
  - AceLewis 4y ago
    You can also not only cache locally but cache nix builds online with services like Cachix. Then you can build a nix env on a powerful dev machine and push to the cache so when the Nix environment is built on a low powered CI machine it can easily download the build instead of trying to build and possibly time out. Build once on one machine and all developers can just download the build.
- kuhsaft 4y ago
  Though it’s like comparing apples and oranges, the primary advantage over containers would be performance. Nix (not to be confused with NixOS) is a package manager. Think of it like apt. Containers on the other hand are (usually) utilizing kernel level isolation to run a whole user space starting with PID 1. These isolation techniques have overhead. Since Nix is a user space application, you can run it in a container and Nix provides one `nixos/nix`.
- callahad 4y ago
  Strictly compared to containers, the big advantages are reproducibility and lower overhead. Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the performance of directly running tools without the risk of clashing with systemwide software. Reproducibility: Nix provides much stronger guarantees about the exact versions of software you're running. It effectively gives you a lockfile for your entire dependency chain, all the way down to libc. Containers tend to be more stateful: everyone on your team may be using the same Dockerfile, but if you build an image from it two weeks apart, you're probably going to get very different outputs due to things like your apt-get update step returning new versions of packages. This doesn't happen with Nix. The beauty is that this isn't either/or; you can actually use Nix to generate OCI container images which are thus fully specified and repeatable.
  - airocker 4y ago
    Would nix guarantee that all upstreams are available forever? Is nix planning to replace all upstreams? (PyPI, Conda, npm etc?) OR does it plan to keep a cache forever?
    - Arcuru 4y ago
      Nix doesn't keep a cache of the upstreams, though there are some projects planning to try to do that I think. The build recipes pull from the original source and use a hash to ensure that the source artifacts don't change. Nix caching is usually done at the build output layer, e.g. the resulting binaries.
      - airocker 4y ago
        So it does plan to replace all up streams eventually including apt, npm, pypi, gem etc by providing the ability to build and configure all software? I am not understanding this, currently the original maintainers release on their own stores. the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain?
- hakre 4y ago
  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.
  - ssgycysdju 4y ago
- paulgb 4y ago
  The core advantage of nix as I understand it (and I would be happy to be corrected if I'm wrong): - Build caching in containers treats the build process as a list of steps: first you do step 1, then step 2, etc. (these correspond to the *layers) of a container). If step 1 changes, you have to re-do step 2, even if it's unrelated; Containers don't have enough context about the commands they are running to know if step 2 depends on step 1. - Build caching in nix is more like a directed acyclic graph: nix understands the steps that depend on other steps, and when something is changed, nix only has to re-run the steps that depended on that step, and the things that depend on them, etc.
- baby 4y ago
  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?)
  - ssgycysdju 4y ago
  - throwawayacc4 4y ago
    Containers run nearly identical to native performance and best VMs in practically every category. In what way are they slow?
    - baby 4y ago
      On my mac it’s really slow to use docker. Maybe I should increase the ram it uses
      - throwawayacc4 4y ago
        I don't use Apple products so I can't help you there. I assume it's doing some networking madness to expose a Linux VM through a bridge or something similar.
      - School-Cotton 4y ago
        Docker containers run in a VM on Mac.
- ruuda 4y ago
  One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. With a Nix-based development environment, it can add/override the tools you need, but you get to keep your shell customizations, editor config, etc. Also reproducibility; it can be achieved with containers if you save the artifact (the container image), but that's not what people do in practice, they save only the recipe (the Dockerfile), and if you execute it tomorrow, it will produce a different result than today, and it will likely not even run one year from now (due to e.g. third-party apt repos changing their url, signing keys expiring, curl|bash installers that are no longer hosted, etc.). With Nix, every run will produce the same results, and sources for everything packaged in Nixpkgs are saved by nixos.org.
  - nordsieck 4y ago
    > One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. Can't you just mount a volume from your host machine? Then you can use your regular editor, and just run commands from inside the container.
    - moojd 4y ago
      On Linux absolutely, the IO latency on MacOS with mounted volumes is atrocious. Using a nix environment also avoids the weird edge cases I tend to run into with volumes mounts and file ownership and such.
    - deleted 4y ago
      [deleted]
    - rgoulter 4y ago
      While it is possible to work with containers to run programs with files on the host, it's just much more convenient to be able to run programs without dealing with mounting issues.
    - ruuda 4y ago
- rgoulter 4y ago
  Nix is good at solving more problems than containers can solve. Nix is good at "programmatically managing packages". For just the problem of "I want to be able to distribute the same application everywhere", container images solve this well. This can also be solved using Nix instead of container images; or Nix can even be used to build the container images. The Nix expression language is much more expressive/powerful/elegant than Dockerfile's syntax is. -- Which can be useful for stuff like declaring "I want <program> built with different build flags / patches". Nix ends up being useful for scratching the itch of "put in effort now, to save effort later".
- Smaug123 4y ago
  Dockerfiles don't compose. If you have two containers and you want to take their union, you are simply out of luck unless you know exactly what you want to take from each one, and you'd better hope they don't interfere with each other. Nix specifications compose perfectly.
- unicornmama 4y ago
  I’ve been burned hard by Nix but I’m going to steel man the argument. - Nix is very good at cross platform support. A single entry-point creates environments on both MacOS and Linux. - Docker containers run slower on MacOS because the virtualization overhead. - Docker images can provide a reproducible environment but the images themselves aren’t reproducible.
antoniojtorres 4y ago
This looks nice! I’m really enthusiastic about these nix based dev env systems. Recently saw devbox[0] here, tried it out and fell in love. It’s made me very interested in all things Nix! 0 - https://news.ycombinator.com/item?id=32600821 https://news.ycombinator.com/item?id=32600821
- sisve 4y ago
  Yes, been using devbox for a while now. It's great. This seems like a direct competitor or? Have anyone compared them?
  - methyl 4y ago
    Big drawback of devbox is that you cannot pin packages to specific SHA, which is quite a big limitation when it comes to versitality. I think you can do that on devenv.sh.
    - dloreto 4y ago
      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.
      - pxc 4y ago
        > 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?
        mikepurvis 4y ago
        From experience just maintaining a private 1000+ package overlay to nixpkgs, this sounds super fraught, at least for any of the scenarios most typically interesting to developers, like wanting a backport of some library version that just landed to your otherwise-stable months old pin 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&size=50&sort=relevance&type=packages&query=Boost https://search.nixos.org/packages?channel=unstable&from=0&si...
stefanha 4y ago
I 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 and development.
- hakre 4y ago
  Err, playing that card in this context looks a bit disconnected to me. Does this suggest a bit of unknowns in Nix and Nix OS?
- yakshaving_jgt 4y ago
  You don’t want to deploy your development tool chain to your production environment, ergo, you want a development environment.
  - crabmusket 4y ago
    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.
    - airocker 4y ago
      ‘Node’ on dev may run differently than node on production depending on version of dependencies , for eg a shared object file it loads.
      - crabmusket 4y ago
        Yes, of course that could happen. All I'm suggesting is that the optimally productive tradeoff is somewhere in between "develop in a full clone of production cloud" and "works on my machine and nowhere else".
crabmusket 4y ago
Seems like Nix is having a bit of a moment. After devbox[1] was released I started looking into Nix, and there's a lot happening. I'm staying away from these Nix wrappers and learning how to do some basic nix-shell work, myself. Until it's proven the wrappers are adding real value, not just trying to hide scary scary Nix from devs who only feel safe in YAML files. For the curious, this post[2] describes mixing Nix and Docker. And this[3] is a pretty decent tutorial on using Nix itself for this use case (consistent developer environments). Without going full NixOS, setting up a shell.nix with some OS-level environmental dependencies is a great way to dabble. It seems there may be a sensible reaction away from "Dockerise all the things" for development at least, e.g. this blog post[4]. There are real downsides to containers for development, even though using things like `rvm`, `nvm` and `venv` were also a pain. We've run into issues ourselves with developers starting to use the new M1 Macs - we've still not figured out how to make filesystem mounting fast yet. There seem to be other advantages to running more things locally, like simpler configuration of debuggers etc. (EDIT for clarity: the issues were with Docker, not Nix, hence the reference to filesystem mounting. Nix == "running more things locally".) But taking a broader view, while containerising apps with complicated dependencies is a win, we really don't need to pretend that production and dev are actually identical environments. For example, only one of these environments needs a compiler. Once you acknowledge that the developer environment shouldn't be fully identical to prod, then you can start to think about what things do need to be the same, what can differ, and what your actual requirements are. [1]: https://www.jetpack.io/devbox/ https://www.jetpack.io/devbox/ [2]: https://ghedam.at/15502/speedy-development-environments-with-nix-and-docker https://ghedam.at/15502/speedy-development-environments-with... [3]: https://nix.dev/tutorials/declarative-and-reproducible-developer-environments#declarative-reproducible-envs https://nix.dev/tutorials/declarative-and-reproducible-devel... [4]: https://blog.testdouble.com/posts/2020-02-11-the-slippery-slope-of-docker-dev-environments/ https://blog.testdouble.com/posts/2020-02-11-the-slippery-sl...
- baby 4y ago
  Indeed we’ve had all sorts of issues with nix and mac (and intel mac as well). Especially tooling like vscode, sublime merge, etc. Oh and I managed to brick nix on my mac, for some reason I can’t even reinstall it. Need to spend more time debugging that. Didn’t play nice with our Rust dependencies as well I found. At least it seemed unnecessarily complicated to set it up with an already existing Rust project.
baby 4y ago
This is great! After spending some time with nix and writing https://mimoo.github.io/nixbyexample/ https://mimoo.github.io/nixbyexample/ I figured it’s too consuming and hard to manage nix yourself. These usable user-facing tools are really what nix needs to go to the next level
colinsane 4y ago
this, 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 competitions, if you can’t relate. the environments i create for these follow similar patterns. it’s either python with numpy, pandas and plotly, or it’s Rust with clap and serde, say. 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). hearing from people who use these tools, nobody has told me that any of these can do this — except that since they crawl up the fs tree looking for their env definition maybe i could just stash some definitions at the fs root and get globally-invokable environments that way. seems hacky though: i’d hope for a method that’s more officially supported.
- stavros 4y ago
  Why can't you have an alias that's basically: mkdir /tmp/my-hourlong-project cp ~/my-env-definitions/python.nix /tmp/my-hourlong-project Is that something like what you mean?
- operator-name 4y ago
  I'm not sure I understand why your suggestion is not applicable? Just keep it at the top of your temp projects and make new temporary directories once inside. Or you could write an alias to do: mkdir tmp/project && cd tmp/project cp ~/stuff/scratchbox.nix . <env-manager-tool> scratchbox.nix You could even use sym/hard links if you wanted to keep the env file up to date.
- idealmedtech 4y ago
  For python specifically, I've found my base anaconda environment to be plenty powerful enough! Sure, it's slow to install packages and create new environments, but anything I'm hacking away on for an hour will probably not be using some crazy specific pip library that I don't already have (at least not the way I prefer to write such projects it won't)
domenkozar 4y ago
Hi all, I'm the author of https://devenv.sh https://devenv.sh, https://cachix.org https://cachix.org and https://nix.dev 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. I'm really looking forward what you build on top of devenv. We're only beginning to explore the area of what's possible, so please give as much feedback as you have.
- haolez 4y ago
  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.
  - ar_lan 4y ago
    Can you elaborate on what about it is clunky? I've used it as my daily driver for the past year so maybe I can help elaborate too.
    - haolez 4y ago
      I felt like I could never find the docs for what I wanted to do. I had a constant feeling that I was doing stupid stuff that's not considered best practices. I've also tried to use it to manage my home dir with some third party tool recommended by the community, but it felt very hacksish compared to the rest of NixOS.
  - aidenn0 4y ago
    I used Gentoo for over 15 years before switching to NixOS. I like it so much better, I'm never going back.
    - Keyframe 4y ago
      How about someone from let's say Ubuntu/Debian or Fedora?
nikolay 4y ago
Man, this took hours to set up on a 2019 MacBook Pro...
- domenkozar 4y ago
  Did you use the Cachix step?
  - nikolay 4y ago
    Yes, of course!
    - domenkozar 4y ago
      Could you paste the output somewhere?
throwaway892238 4y ago
Good luck to them, but I'll never use Nix. It's as obscure and annoying as Gentoo (or maybe more) with no practical benefits over anything else.
- deleted 4y ago
  [deleted]
- v3ss0n 4y ago
  No, it'd not about using nixos
airocker 4y ago
I 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.
- crabmusket 4y ago
  But unless you're doing all your development on cloud servers that exactly mirror the deployment architecture of your production cloud (I'm assuming we're discussing cloud application development here), then the environments are already different. Some differences are incidental (e.g. developers using different operating systems) and Docker can help reduce those, for sure. By some differences are essential and desirable (e.g. you don't deploy your compiler). I'm starting to think it's best to first reduce the number of differences that matter. E.g. if you're using an interpreteded language, reduce or isolate native dependencies so that most code can just depend on the right runtime version.
- wg0 4y ago
  Don't know why it is downvoted but isn't it a legitimate concern that if dev and prod environments are produced differently with different tool chains, it might result in discrepancies? Concrete example, dev environment with nix but production is Dockerfile with apt getting packages? Thoughts?
  - ghostwriter 4y ago
    That question never stopped developers from getting Apple hardware and OSX at their workplaces and it seems they've been productive, even though hardly anyone except mobile developers deploy anything on OSX. Besides, what's the point of having a production environment based on apt if it can be derived from the same graph of all dependencies that you use for building and running your software locally by Nix? [1] There isn't need for apt-based images if you've been utilizing Nix already. [1] https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerTools-buildImage https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...
ssgycysdju 4y ago
charliermarsh 4y ago
Another project I've been following in this space (no affiliation) is Tangram (https://www.tangram.dev/ https://www.tangram.dev/), which I think of as "Nix, but TypeScript" -- or, from their Discord: > Tangram takes a lot of inspiration from nix, and could be described as a mix between nix and bazel where you write JS/TS
- yewenjie 4y ago
  Looks like there is no source available or even installation option?
  - crabmusket 4y ago
    I assume there is more information in their Discord? I'm not joining just to find out though.
  - 22c 4y ago
    There's this https://github.com/tangramdotdev https://github.com/tangramdotdev but I don't know what project among these GP was specifically referring to, perhaps it's not public at the moment
nvln 4y ago
There is also devshell[1] which allows you to configure specific commands for your `env` and sits inside your flake. [1]: https://github.com/numtide/devshell https://github.com/numtide/devshell
solatic 4y ago
There's a long tail of issues that continue to plague Nix. Sometimes, not even the fault of the Nix project itself. Case in point for my current employer's Python shop - everyone runs PyCharm. Well, JetBrains doesn't really support Nix-based environments. See e.g. https://youtrack.jetbrains.com/issue/PY-42461 https://youtrack.jetbrains.com/issue/PY-42461 . So basically something like this would be DOA. Is this something that someone like @domenkozar can fix? @grhmc ? I don't know.
- andyrichardson 4y ago
  Having used Fedora Silverblue in the past, I went all in on nixOS as it seemed perfect for me. Setup was easier than Arch and I had more trust in the stability of the system because there's no state/config that I wasn't aware of (albeit after a learning curve). The biggest issue though is how rigid it is. The "nix way" spreads like a plague into everything and I often felt like I couldn't do basic tasks such as install some node modules without having to relearn how to do it in nix. I told myself that FHS was a good enough fallback, but that just wasn't the case. Despite using FHS for node development, I still encountered nix-specific issues that needed a nix-specific fix (i.e. using prisma binaries).
  - solatic 4y ago
    Yeah I ran into this with Flutter, where upstream's install method boiled down to "Clone the Git repo and allow Flutter to write into the path where the repo is cloned to in an ad-hoc manner." Needless to say, huge conflict with the Nix Way. When the Flutter 2 -> 3 migration happened, the upgrade for the Nix package was taking so long (months) that I eventually said, you know what, screw it, I can't let productivity get bogged down for a reason like that. I still believe that the Nix way is the right approach, it's just going to take more time to mature out the Nix ecosystem's integrations with various language and package ecosystems to make it more dependable for developers.
1letterunixname 4y ago
The only way to get reproducible environments is to have an immutable base OS with packages compiled without environment, library, or fs leaks. In the real world, this requires lots of patching and isolation (hypervisor and/or containers). Unfortunately, Nix suffers the fate of Haskell: so powerful that the masses can't and don't use it. By contrast, Homebrew spreads like cancer. "Worse is better".
- colordrops 4y ago
  Plenty of us are using it. But it would be great if it were more mainstream, yes.
  - rofrol 4y ago
    wishful thinking. nix is not mainstream
jbverschoor 4y ago
Will this create a container/vm for your env? The current state of the software supply chain makes me very uncomfortable to install any packages.
grudg3 4y ago
This looks interesting but it seems that if you're wanting to use specific versions of two separate packages, that are not in the same nixpkgs commit, you're a bit out of luck. For example, if I want to use an older version of Terraform with a newer version of the Terraform AzureRM provider, I couldn't quite figure out a way to do it...
- madduci 4y ago
  And isolated GUI apps would be also nice to have
- domenkozar 4y ago
  That's something that still needs to be supported and I'll be working on it next week as part of the https://oceansprint.org https://oceansprint.org
oxff 4y ago
> Anything about Nix > fast Massive doubt.jpeg, as all my previous attempts at understanding and using Nix have all been "trust me bro, THIS random github repo source code has the Current Best Practice (already outdated)" and various other random two article blogs on how great nix is.
weitzj 4y ago
I still struggle to have the esp32 Cross Compiler Toolchain with the esp-rust llvm Compiler fork working with Nix. Everything without the Esp32 rust Compiler is already in nix pkg. Also when trying to adopt nix for the enterprise it is still a tough barrier. At least for me struggling how to package something like the synology active backup client nix or how to setup your cups printers in nixos. Besides that I hope for nix to get secure boot support.
avidphantasm 4y ago
Going to ask a naive and possibly lazy question. On macOS does this replace Homebrew and MacPorts? I used to use MacPorts, now Homebrew. However, I’m thinking of switching back to MacPorts due to how painful using prior package versions is in Homebrew; sometimes I can’t run bleeding edge versions, and Homebrew’s all or nothing approach to versions isn’t working for me anymore. I use Python with a few key native packages that are a pain to build myself (NumPy, GDAL primarily). Should I be considering Nix instead of MacPorts?
- ArmandGrillet 4y ago
  > On macOS does this replace Homebrew and MacPorts? I use Homebrew for casks and the few CLI tools I need for all my projects (e.g. the Github CLI tool) and I use Nix for CLI tools I need to work on a specific repository using specific versions (e.g. node).
  - pxc 4y ago
    Seconding this! When I'm on a Mac, I use Homebrew only for casks (automatically downloading .apps and DMGs for macOS GUI), and Nix for project-specific development environments. I do also like to use Nix for globally available packages, though, especially via Nix-Darwin.
plq 4y ago
We are using Gentoo Prefix [1] project to set up our development environment on linux. Containers etc. aren't needed as long as the elf interpreter path and rpath are set up correctly when linking the executable (or with patchelf afterwards). Highly recommended. [1]: https://wiki.gentoo.org/wiki/Project:Prefix https://wiki.gentoo.org/wiki/Project:Prefix
deleted 4y ago
[deleted]
roythatapp 4y ago
Did somebody try floxdev.com? That's pretty much doing the job.
pikanix 4y ago
Love the experiments coming out these days: this, flox, even Replit. All working on diff approaches to a "Nix UX". Someone's going to get it right...
Jabdoa2 4y ago
Is there a way to specify a specific version of a language in devenv? I checked to docs and even read the nix tutorial but could not figure this out. I like to idea of having this in every repository in our codebase. Would make bootstrapping easier for new developers. However, you often want a specific golang or python version. Once you update some tool or language everybody gets the new env. That would be neat. Is that possible somehow? I guess initially we would roll this out just for dev and keep Dockerfiles how they are but eventually we could then use it as builder in docker. Bonus question: Can I use devenv/nix together with Bazel? We use that in quite a few newer projects and it also suffers from the local dev env issue.
- domenkozar 4y ago
  Specifying language versions is planned. Versions are locked using devenv.lock and everyone gets the same version.
td7x 4y ago
Nix newbie, welcoming a lower entry - but is devenv.sh still nix? For example, is the devenv cli needed or is it extra?

382 points by frankpf 4y ago

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.

judge2020 4y ago
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.
- callahad 4y ago
  I believe you are mistaken; Nix has no intrinsic connection to cgroups / containers.
  - ghostwriter 4y ago
    how does it enforce FS and network isolation?
    - InvaderFizz 4y ago
      It doesn't. Nix is basically a whole load of compiled dependencies pathed to /nix/hash/dependency So you can have things that would ordinarily be dependency hell running side by side because foo that requires bar6 is compiled against that, and baz that requires bar7 is linked against that. Both versions of bar are present in the nix structure, on a specific path that the software is compiled against.
      - pxc 4y ago
        To summarize this in a metaphor: Nix 'isolates' packages by ensuring that they do not know where to look for each other, rather than ensuring that they cannot possibly see each other. In addition to the example given by the parent poster, here are some other steps taken towards that end in the Nix ecosystem: Nix-built programs look for their libs, they don't see libs other than what they were built with because each package has its own little FHS-shaped tree, which it thinks of in the way a 'normal' package might think of as 'the system'— that thing which has a `/usr/lib` in which to find libraries and a `/etc` in which to find config files and a `/usr/share` in which to find assets, etc. In addition to linking against hardcoded full paths to dependencies, outlined above, maintainers also take steps to ensure that, e.g., external programs referenced in shell scripts in a Nix package also refer to full paths into the Nix store.
      - ghostwriter 4y ago
        How do you mean it doesn't if the manual itself says that: "In addition, on Linux, builds run in private PID, mount, network, IPC and UTS namespaces to isolate them from other processes in the system"? https://nixos.org/manual/nix/stable/command-ref/conf-file.html#conf-sandbox https://nixos.org/manual/nix/stable/command-ref/conf-file.ht...
        callahad 4y ago
        "Builds" is the operative word there: that specific isolation is optional and only applies during compilation.
- mikepurvis 4y ago
  It uses some of that stuff to isolate its background build sandbox, but none of it affects a normal nix subshell.
- pxc 4y ago
  Nix has configurable support for build sandboxing. On Linux, that sandboxing is enabled by default, but builds and installs and everything work fine without it. 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.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
carlmr 4y ago
One thing is perfect caching. Each package is cached in its own folder, so if you exchange one package you don't have to rebuild the rest of the image. Also you can have multiple versions of the package cached. Also all your environments benefit from the cache, since each "layer" is independent. Docker's layer based caching is very limiting for larger images. With Nix you spend basically no time on incremental builds outside of the time for the one package you changed.
- AceLewis 4y ago
  You can also not only cache locally but cache nix builds online with services like Cachix. Then you can build a nix env on a powerful dev machine and push to the cache so when the Nix environment is built on a low powered CI machine it can easily download the build instead of trying to build and possibly time out. Build once on one machine and all developers can just download the build.
kuhsaft 4y ago
Though it’s like comparing apples and oranges, the primary advantage over containers would be performance. Nix (not to be confused with NixOS) is a package manager. Think of it like apt. Containers on the other hand are (usually) utilizing kernel level isolation to run a whole user space starting with PID 1. These isolation techniques have overhead. Since Nix is a user space application, you can run it in a container and Nix provides one `nixos/nix`.
callahad 4y ago
Strictly compared to containers, the big advantages are reproducibility and lower overhead. Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the performance of directly running tools without the risk of clashing with systemwide software. Reproducibility: Nix provides much stronger guarantees about the exact versions of software you're running. It effectively gives you a lockfile for your entire dependency chain, all the way down to libc. Containers tend to be more stateful: everyone on your team may be using the same Dockerfile, but if you build an image from it two weeks apart, you're probably going to get very different outputs due to things like your apt-get update step returning new versions of packages. This doesn't happen with Nix. The beauty is that this isn't either/or; you can actually use Nix to generate OCI container images which are thus fully specified and repeatable.
- airocker 4y ago
  Would nix guarantee that all upstreams are available forever? Is nix planning to replace all upstreams? (PyPI, Conda, npm etc?) OR does it plan to keep a cache forever?
  - Arcuru 4y ago
    Nix doesn't keep a cache of the upstreams, though there are some projects planning to try to do that I think. The build recipes pull from the original source and use a hash to ensure that the source artifacts don't change. Nix caching is usually done at the build output layer, e.g. the resulting binaries.
    - airocker 4y ago
      So it does plan to replace all up streams eventually including apt, npm, pypi, gem etc by providing the ability to build and configure all software? I am not understanding this, currently the original maintainers release on their own stores. the build and configure steps may change over time. Unless the original maintainers start building for nix, would not this be too hard to maintain?
hakre 4y ago
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.
- ssgycysdju 4y ago
paulgb 4y ago
The core advantage of nix as I understand it (and I would be happy to be corrected if I'm wrong): - Build caching in containers treats the build process as a list of steps: first you do step 1, then step 2, etc. (these correspond to the *layers) of a container). If step 1 changes, you have to re-do step 2, even if it's unrelated; Containers don't have enough context about the commands they are running to know if step 2 depends on step 1. - Build caching in nix is more like a directed acyclic graph: nix understands the steps that depend on other steps, and when something is changed, nix only has to re-run the steps that depended on that step, and the things that depend on them, etc.
baby 4y ago
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?)
- ssgycysdju 4y ago
- throwawayacc4 4y ago
  Containers run nearly identical to native performance and best VMs in practically every category. In what way are they slow?
  - baby 4y ago
    On my mac it’s really slow to use docker. Maybe I should increase the ram it uses
    - throwawayacc4 4y ago
      I don't use Apple products so I can't help you there. I assume it's doing some networking madness to expose a Linux VM through a bridge or something similar.
    - School-Cotton 4y ago
      Docker containers run in a VM on Mac.
ruuda 4y ago
One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. With a Nix-based development environment, it can add/override the tools you need, but you get to keep your shell customizations, editor config, etc. Also reproducibility; it can be achieved with containers if you save the artifact (the container image), but that's not what people do in practice, they save only the recipe (the Dockerfile), and if you execute it tomorrow, it will produce a different result than today, and it will likely not even run one year from now (due to e.g. third-party apt repos changing their url, signing keys expiring, curl|bash installers that are no longer hosted, etc.). With Nix, every run will produce the same results, and sources for everything packaged in Nixpkgs are saved by nixos.org.
- nordsieck 4y ago
  > One difference is that Docker containers use a separate file system isolated from the host, so you have to separately install your editor/shell in there, mount/clone your dotfiles, etc. Can't you just mount a volume from your host machine? Then you can use your regular editor, and just run commands from inside the container.
  - moojd 4y ago
    On Linux absolutely, the IO latency on MacOS with mounted volumes is atrocious. Using a nix environment also avoids the weird edge cases I tend to run into with volumes mounts and file ownership and such.
  - deleted 4y ago
    [deleted]
  - rgoulter 4y ago
    While it is possible to work with containers to run programs with files on the host, it's just much more convenient to be able to run programs without dealing with mounting issues.
  - ruuda 4y ago
rgoulter 4y ago
Nix is good at solving more problems than containers can solve. Nix is good at "programmatically managing packages". For just the problem of "I want to be able to distribute the same application everywhere", container images solve this well. This can also be solved using Nix instead of container images; or Nix can even be used to build the container images. The Nix expression language is much more expressive/powerful/elegant than Dockerfile's syntax is. -- Which can be useful for stuff like declaring "I want <program> built with different build flags / patches". Nix ends up being useful for scratching the itch of "put in effort now, to save effort later".
Smaug123 4y ago
Dockerfiles don't compose. If you have two containers and you want to take their union, you are simply out of luck unless you know exactly what you want to take from each one, and you'd better hope they don't interfere with each other. Nix specifications compose perfectly.
unicornmama 4y ago
I’ve been burned hard by Nix but I’m going to steel man the argument. - Nix is very good at cross platform support. A single entry-point creates environments on both MacOS and Linux. - Docker containers run slower on MacOS because the virtualization overhead. - Docker images can provide a reproducible environment but the images themselves aren’t reproducible.

antoniojtorres 4y ago

This looks nice! I’m really enthusiastic about these nix based dev env systems. Recently saw devbox[0] here, tried it out and fell in love. It’s made me very interested in all things Nix! 0 - https://news.ycombinator.com/item?id=32600821 https://news.ycombinator.com/item?id=32600821

sisve 4y ago
Yes, been using devbox for a while now. It's great. This seems like a direct competitor or? Have anyone compared them?
- methyl 4y ago
  Big drawback of devbox is that you cannot pin packages to specific SHA, which is quite a big limitation when it comes to versitality. I think you can do that on devenv.sh.
  - dloreto 4y ago
    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.
    - pxc 4y ago
      > 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?
      - mikepurvis 4y ago
        From experience just maintaining a private 1000+ package overlay to nixpkgs, this sounds super fraught, at least for any of the scenarios most typically interesting to developers, like wanting a backport of some library version that just landed to your otherwise-stable months old pin 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&size=50&sort=relevance&type=packages&query=Boost https://search.nixos.org/packages?channel=unstable&from=0&si...

stefanha 4y ago

I 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 and development.

hakre 4y ago
Err, playing that card in this context looks a bit disconnected to me. Does this suggest a bit of unknowns in Nix and Nix OS?
yakshaving_jgt 4y ago
You don’t want to deploy your development tool chain to your production environment, ergo, you want a development environment.
- crabmusket 4y ago
  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.
  - airocker 4y ago
    ‘Node’ on dev may run differently than node on production depending on version of dependencies , for eg a shared object file it loads.
    - crabmusket 4y ago
      Yes, of course that could happen. All I'm suggesting is that the optimally productive tradeoff is somewhere in between "develop in a full clone of production cloud" and "works on my machine and nowhere else".

crabmusket 4y ago

Seems like Nix is having a bit of a moment. After devbox[1] was released I started looking into Nix, and there's a lot happening. I'm staying away from these Nix wrappers and learning how to do some basic nix-shell work, myself. Until it's proven the wrappers are adding real value, not just trying to hide scary scary Nix from devs who only feel safe in YAML files. For the curious, this post[2] describes mixing Nix and Docker. And this[3] is a pretty decent tutorial on using Nix itself for this use case (consistent developer environments). Without going full NixOS, setting up a shell.nix with some OS-level environmental dependencies is a great way to dabble. It seems there may be a sensible reaction away from "Dockerise all the things" for development at least, e.g. this blog post[4]. There are real downsides to containers for development, even though using things like `rvm`, `nvm` and `venv` were also a pain. We've run into issues ourselves with developers starting to use the new M1 Macs - we've still not figured out how to make filesystem mounting fast yet. There seem to be other advantages to running more things locally, like simpler configuration of debuggers etc. (EDIT for clarity: the issues were with Docker, not Nix, hence the reference to filesystem mounting. Nix == "running more things locally".) But taking a broader view, while containerising apps with complicated dependencies is a win, we really don't need to pretend that production and dev are actually identical environments. For example, only one of these environments needs a compiler. Once you acknowledge that the developer environment shouldn't be fully identical to prod, then you can start to think about what things do need to be the same, what can differ, and what your actual requirements are. [1]: https://www.jetpack.io/devbox/ https://www.jetpack.io/devbox/ [2]: https://ghedam.at/15502/speedy-development-environments-with-nix-and-docker https://ghedam.at/15502/speedy-development-environments-with... [3]: https://nix.dev/tutorials/declarative-and-reproducible-developer-environments#declarative-reproducible-envs https://nix.dev/tutorials/declarative-and-reproducible-devel... [4]: https://blog.testdouble.com/posts/2020-02-11-the-slippery-slope-of-docker-dev-environments/ https://blog.testdouble.com/posts/2020-02-11-the-slippery-sl...

baby 4y ago
Indeed we’ve had all sorts of issues with nix and mac (and intel mac as well). Especially tooling like vscode, sublime merge, etc. Oh and I managed to brick nix on my mac, for some reason I can’t even reinstall it. Need to spend more time debugging that. Didn’t play nice with our Rust dependencies as well I found. At least it seemed unnecessarily complicated to set it up with an already existing Rust project.

baby 4y ago

This is great! After spending some time with nix and writing https://mimoo.github.io/nixbyexample/ https://mimoo.github.io/nixbyexample/ I figured it’s too consuming and hard to manage nix yourself. These usable user-facing tools are really what nix needs to go to the next level

colinsane 4y ago

this, 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 competitions, if you can’t relate. the environments i create for these follow similar patterns. it’s either python with numpy, pandas and plotly, or it’s Rust with clap and serde, say. 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). hearing from people who use these tools, nobody has told me that any of these can do this — except that since they crawl up the fs tree looking for their env definition maybe i could just stash some definitions at the fs root and get globally-invokable environments that way. seems hacky though: i’d hope for a method that’s more officially supported.

stavros 4y ago
Why can't you have an alias that's basically: mkdir /tmp/my-hourlong-project cp ~/my-env-definitions/python.nix /tmp/my-hourlong-project Is that something like what you mean?
operator-name 4y ago
I'm not sure I understand why your suggestion is not applicable? Just keep it at the top of your temp projects and make new temporary directories once inside. Or you could write an alias to do: mkdir tmp/project && cd tmp/project cp ~/stuff/scratchbox.nix . <env-manager-tool> scratchbox.nix You could even use sym/hard links if you wanted to keep the env file up to date.
idealmedtech 4y ago
For python specifically, I've found my base anaconda environment to be plenty powerful enough! Sure, it's slow to install packages and create new environments, but anything I'm hacking away on for an hour will probably not be using some crazy specific pip library that I don't already have (at least not the way I prefer to write such projects it won't)

domenkozar 4y ago

Hi all, I'm the author of https://devenv.sh https://devenv.sh, https://cachix.org https://cachix.org and https://nix.dev 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. I'm really looking forward what you build on top of devenv. We're only beginning to explore the area of what's possible, so please give as much feedback as you have.

haolez 4y ago
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.
- ar_lan 4y ago
  Can you elaborate on what about it is clunky? I've used it as my daily driver for the past year so maybe I can help elaborate too.
  - haolez 4y ago
    I felt like I could never find the docs for what I wanted to do. I had a constant feeling that I was doing stupid stuff that's not considered best practices. I've also tried to use it to manage my home dir with some third party tool recommended by the community, but it felt very hacksish compared to the rest of NixOS.
- aidenn0 4y ago
  I used Gentoo for over 15 years before switching to NixOS. I like it so much better, I'm never going back.
  - Keyframe 4y ago
    How about someone from let's say Ubuntu/Debian or Fedora?

nikolay 4y ago

Man, this took hours to set up on a 2019 MacBook Pro...

domenkozar 4y ago
Did you use the Cachix step?
- nikolay 4y ago
  Yes, of course!
  - domenkozar 4y ago
    Could you paste the output somewhere?

throwaway892238 4y ago

Good luck to them, but I'll never use Nix. It's as obscure and annoying as Gentoo (or maybe more) with no practical benefits over anything else.

deleted 4y ago
[deleted]
v3ss0n 4y ago
No, it'd not about using nixos

airocker 4y ago

I 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.

crabmusket 4y ago
But unless you're doing all your development on cloud servers that exactly mirror the deployment architecture of your production cloud (I'm assuming we're discussing cloud application development here), then the environments are already different. Some differences are incidental (e.g. developers using different operating systems) and Docker can help reduce those, for sure. By some differences are essential and desirable (e.g. you don't deploy your compiler). I'm starting to think it's best to first reduce the number of differences that matter. E.g. if you're using an interpreteded language, reduce or isolate native dependencies so that most code can just depend on the right runtime version.
wg0 4y ago
Don't know why it is downvoted but isn't it a legitimate concern that if dev and prod environments are produced differently with different tool chains, it might result in discrepancies? Concrete example, dev environment with nix but production is Dockerfile with apt getting packages? Thoughts?
- ghostwriter 4y ago
  That question never stopped developers from getting Apple hardware and OSX at their workplaces and it seems they've been productive, even though hardly anyone except mobile developers deploy anything on OSX. Besides, what's the point of having a production environment based on apt if it can be derived from the same graph of all dependencies that you use for building and running your software locally by Nix? [1] There isn't need for apt-based images if you've been utilizing Nix already. [1] https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerTools-buildImage https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...

ssgycysdju 4y ago

charliermarsh 4y ago

Another project I've been following in this space (no affiliation) is Tangram (https://www.tangram.dev/ https://www.tangram.dev/), which I think of as "Nix, but TypeScript" -- or, from their Discord: > Tangram takes a lot of inspiration from nix, and could be described as a mix between nix and bazel where you write JS/TS

yewenjie 4y ago
Looks like there is no source available or even installation option?
- crabmusket 4y ago
  I assume there is more information in their Discord? I'm not joining just to find out though.
- 22c 4y ago
  There's this https://github.com/tangramdotdev https://github.com/tangramdotdev but I don't know what project among these GP was specifically referring to, perhaps it's not public at the moment

nvln 4y ago

There is also devshell[1] which allows you to configure specific commands for your `env` and sits inside your flake. [1]: https://github.com/numtide/devshell https://github.com/numtide/devshell

solatic 4y ago

There's a long tail of issues that continue to plague Nix. Sometimes, not even the fault of the Nix project itself. Case in point for my current employer's Python shop - everyone runs PyCharm. Well, JetBrains doesn't really support Nix-based environments. See e.g. https://youtrack.jetbrains.com/issue/PY-42461 https://youtrack.jetbrains.com/issue/PY-42461 . So basically something like this would be DOA. Is this something that someone like @domenkozar can fix? @grhmc ? I don't know.

andyrichardson 4y ago
Having used Fedora Silverblue in the past, I went all in on nixOS as it seemed perfect for me. Setup was easier than Arch and I had more trust in the stability of the system because there's no state/config that I wasn't aware of (albeit after a learning curve). The biggest issue though is how rigid it is. The "nix way" spreads like a plague into everything and I often felt like I couldn't do basic tasks such as install some node modules without having to relearn how to do it in nix. I told myself that FHS was a good enough fallback, but that just wasn't the case. Despite using FHS for node development, I still encountered nix-specific issues that needed a nix-specific fix (i.e. using prisma binaries).
- solatic 4y ago
  Yeah I ran into this with Flutter, where upstream's install method boiled down to "Clone the Git repo and allow Flutter to write into the path where the repo is cloned to in an ad-hoc manner." Needless to say, huge conflict with the Nix Way. When the Flutter 2 -> 3 migration happened, the upgrade for the Nix package was taking so long (months) that I eventually said, you know what, screw it, I can't let productivity get bogged down for a reason like that. I still believe that the Nix way is the right approach, it's just going to take more time to mature out the Nix ecosystem's integrations with various language and package ecosystems to make it more dependable for developers.

1letterunixname 4y ago

The only way to get reproducible environments is to have an immutable base OS with packages compiled without environment, library, or fs leaks. In the real world, this requires lots of patching and isolation (hypervisor and/or containers). Unfortunately, Nix suffers the fate of Haskell: so powerful that the masses can't and don't use it. By contrast, Homebrew spreads like cancer. "Worse is better".

colordrops 4y ago
Plenty of us are using it. But it would be great if it were more mainstream, yes.
- rofrol 4y ago
  wishful thinking. nix is not mainstream

jbverschoor 4y ago

Will this create a container/vm for your env? The current state of the software supply chain makes me very uncomfortable to install any packages.

grudg3 4y ago

This looks interesting but it seems that if you're wanting to use specific versions of two separate packages, that are not in the same nixpkgs commit, you're a bit out of luck. For example, if I want to use an older version of Terraform with a newer version of the Terraform AzureRM provider, I couldn't quite figure out a way to do it...

madduci 4y ago
And isolated GUI apps would be also nice to have
domenkozar 4y ago
That's something that still needs to be supported and I'll be working on it next week as part of the https://oceansprint.org https://oceansprint.org

oxff 4y ago

> Anything about Nix > fast Massive doubt.jpeg, as all my previous attempts at understanding and using Nix have all been "trust me bro, THIS random github repo source code has the Current Best Practice (already outdated)" and various other random two article blogs on how great nix is.

weitzj 4y ago

I still struggle to have the esp32 Cross Compiler Toolchain with the esp-rust llvm Compiler fork working with Nix. Everything without the Esp32 rust Compiler is already in nix pkg. Also when trying to adopt nix for the enterprise it is still a tough barrier. At least for me struggling how to package something like the synology active backup client nix or how to setup your cups printers in nixos. Besides that I hope for nix to get secure boot support.

avidphantasm 4y ago

Going to ask a naive and possibly lazy question. On macOS does this replace Homebrew and MacPorts? I used to use MacPorts, now Homebrew. However, I’m thinking of switching back to MacPorts due to how painful using prior package versions is in Homebrew; sometimes I can’t run bleeding edge versions, and Homebrew’s all or nothing approach to versions isn’t working for me anymore. I use Python with a few key native packages that are a pain to build myself (NumPy, GDAL primarily). Should I be considering Nix instead of MacPorts?

ArmandGrillet 4y ago
> On macOS does this replace Homebrew and MacPorts? I use Homebrew for casks and the few CLI tools I need for all my projects (e.g. the Github CLI tool) and I use Nix for CLI tools I need to work on a specific repository using specific versions (e.g. node).
- pxc 4y ago
  Seconding this! When I'm on a Mac, I use Homebrew only for casks (automatically downloading .apps and DMGs for macOS GUI), and Nix for project-specific development environments. I do also like to use Nix for globally available packages, though, especially via Nix-Darwin.

plq 4y ago

We are using Gentoo Prefix [1] project to set up our development environment on linux. Containers etc. aren't needed as long as the elf interpreter path and rpath are set up correctly when linking the executable (or with patchelf afterwards). Highly recommended. [1]: https://wiki.gentoo.org/wiki/Project:Prefix https://wiki.gentoo.org/wiki/Project:Prefix

deleted 4y ago

[deleted]

roythatapp 4y ago

Did somebody try floxdev.com? That's pretty much doing the job.

pikanix 4y ago

Love the experiments coming out these days: this, flox, even Replit. All working on diff approaches to a "Nix UX". Someone's going to get it right...

Jabdoa2 4y ago

Is there a way to specify a specific version of a language in devenv? I checked to docs and even read the nix tutorial but could not figure this out. I like to idea of having this in every repository in our codebase. Would make bootstrapping easier for new developers. However, you often want a specific golang or python version. Once you update some tool or language everybody gets the new env. That would be neat. Is that possible somehow? I guess initially we would roll this out just for dev and keep Dockerfiles how they are but eventually we could then use it as builder in docker. Bonus question: Can I use devenv/nix together with Bazel? We use that in quite a few newer projects and it also suffers from the local dev env issue.

domenkozar 4y ago
Specifying language versions is planned. Versions are locked using devenv.lock and everyone gets the same version.

td7x 4y ago

Nix newbie, welcoming a lower entry - but is devenv.sh still nix? For example, is the devenv cli needed or is it extra?