Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
NixOS-docker
Discontinued DEPRECATED! Dockerfiles to package Nix in a minimal docker container (by NixOS)
-
not-os
An operating system generator, based on NixOS, that, given a config, outputs a small (47 MB), read-only squashfs for a runit-based operating system, with support for iPXE and signed boot.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
napalm
Support for building npm packages in Nix and lightweight npm registry [maintainer @jtojnar] (by nix-community)
-
-
spack
A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
-
-
-
archbox
Easy to use Arch Linux chroot environment with some functionalities to integrate it with your existing Linux installation. Mirror of https://momodev.lemniskett.moe/lemniskett/archbox
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
One way is to use this project: https://github.com/nix-community/nixos-generators
It's just a small wrapper but it shows you most of the targets available.
- poetry can still be used by people who don't use Nix
Regarding non-python dependencies, this is solved by overrides file[1]. You can override the override in your project as well.
[1] https://github.com/nix-community/poetry2nix/blob/master/over...
There is one: https://github.com/NixOS/docker
But it's more of a Nix docker image than a NixOS one, because half of the things that NixOS gives you don't really make much sense in a docker image (systemd in a container?).
It's like an OS that has builtin salt/ansible/chef/puppet.
Because Nix language describe the OS instead of what to change/configure it's superior to these tools, and solves the problem that supposedly same machines are drifting apart.
For example if in the CM you tell it to install a package, then change your mind and remove the entry that does it. The package will remain installed.
With NixOS if you remove the package from configuration, it's gone.
I personally really like Nix's building capability. For example I can use it to generate a minimal docker container. It requires some knowledge, but I can also modify compilation options in dependencies (like remove unneeded functionality).
It looks like there's also an option to similarly build lightweight OS images[1]. I haven't tried it yet but looks cool.
[1] https://github.com/cleverca22/not-os
A teeny-tiny orientation for (prospective?) Nix newcomers:
Having spent years on Arch and Gentoo, imo the NixOS community is outstanding even among 'advanced' Linux distros in terms of expertise and kindness.
I'll never forget one time I was having problems with a Python package generation tool and when I mentioned it on IRC, and one of its authors (Rok Garbas, who is so quite active in the community) just hopped on a call to debug the issue I was having right then and there.
If you're on the fence about Nix and that kind of community is valuable to you, make sure to check out the forums [1] and realtime chat [2] (the latter of which is unfortunately still in the process [3] of migrating away from Freenode).
If personal assistance/mentorship of the kind I described at the beginning of this post is appealing to you, several generous and knowledgeable community members host Nix ‘office hours’ [4]. I'm not sure who all are still running them, but I know tomberek is for sure [5] and you can find a link in the footnotes.
There is one serious problem with NixOS and the wider ecosystem right now, namely that the best experience available depends on Nix features that are unreleased. Nix makes it very easy to run bleeding edge builds of Nix and enable these features, but the unofficial status of it all has slowed adoption, integration, and documentation of these tools in the wider community.
That aside— i.e., if you're willing to be a little bit of a pioneer— the community is on the whole pretty rich with good documentation of everything but the bleeding edge, unreleased bits at this point. Those pieces mostly impact the CLI and specifying inputs to the expressions you use to define your system. Everything in the NixOS and Nixpkgs manuals is still accurate. The unreleased components are also fairly mature despite their unofficial status: many folks in the community have been using them for a year or two now.
Finally: if you're interested in dipping your toes in without committing to a system fully managed by Nix and you're a macOS user, nix-darwin [6] provides a pretty NixOS-like experience using a module system and CLI based on NixOS'. There's nothing equally complete in terms of managing system services in a declarative fashion on non-NixOS Linux, but home-manager [7] provides some functionality for enabling user-mode services in a declarative style.
You can check whether your favorite software is packaged for Nix here [8], and additionally NixOS does support several other forms of cross-distro packaging/deployment, including Flatpak, Snap, AppImage, and Docker. Steam support is native and works without much fuss, too.
---------
1: https://discourse.nixos.org/
2: https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org
3: https://github.com/NixOS/rfcs/pull/94
4: https://discourse.nixos.org/search?q=office%20hours
5: https://discourse.nixos.org/t/nix-office-hours/11945
6: https://github.com/LnL7/nix-darwin
7: https://github.com/nix-community/home-manager
8: https://search.nixos.org/packages
A teeny-tiny orientation for (prospective?) Nix newcomers:
Having spent years on Arch and Gentoo, imo the NixOS community is outstanding even among 'advanced' Linux distros in terms of expertise and kindness.
I'll never forget one time I was having problems with a Python package generation tool and when I mentioned it on IRC, and one of its authors (Rok Garbas, who is so quite active in the community) just hopped on a call to debug the issue I was having right then and there.
If you're on the fence about Nix and that kind of community is valuable to you, make sure to check out the forums [1] and realtime chat [2] (the latter of which is unfortunately still in the process [3] of migrating away from Freenode).
If personal assistance/mentorship of the kind I described at the beginning of this post is appealing to you, several generous and knowledgeable community members host Nix ‘office hours’ [4]. I'm not sure who all are still running them, but I know tomberek is for sure [5] and you can find a link in the footnotes.
There is one serious problem with NixOS and the wider ecosystem right now, namely that the best experience available depends on Nix features that are unreleased. Nix makes it very easy to run bleeding edge builds of Nix and enable these features, but the unofficial status of it all has slowed adoption, integration, and documentation of these tools in the wider community.
That aside— i.e., if you're willing to be a little bit of a pioneer— the community is on the whole pretty rich with good documentation of everything but the bleeding edge, unreleased bits at this point. Those pieces mostly impact the CLI and specifying inputs to the expressions you use to define your system. Everything in the NixOS and Nixpkgs manuals is still accurate. The unreleased components are also fairly mature despite their unofficial status: many folks in the community have been using them for a year or two now.
Finally: if you're interested in dipping your toes in without committing to a system fully managed by Nix and you're a macOS user, nix-darwin [6] provides a pretty NixOS-like experience using a module system and CLI based on NixOS'. There's nothing equally complete in terms of managing system services in a declarative fashion on non-NixOS Linux, but home-manager [7] provides some functionality for enabling user-mode services in a declarative style.
You can check whether your favorite software is packaged for Nix here [8], and additionally NixOS does support several other forms of cross-distro packaging/deployment, including Flatpak, Snap, AppImage, and Docker. Steam support is native and works without much fuss, too.
---------
1: https://discourse.nixos.org/
2: https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org
3: https://github.com/NixOS/rfcs/pull/94
4: https://discourse.nixos.org/search?q=office%20hours
5: https://discourse.nixos.org/t/nix-office-hours/11945
6: https://github.com/LnL7/nix-darwin
7: https://github.com/nix-community/home-manager
8: https://search.nixos.org/packages
My hope is that when Sander van der Burg finishes drafting his RFC for mainlining his process management framework [1], which abstracts over ways to manage local services from systemd to supervisord to Docker, we can actually unify the module collection in Nixpkgs with its clones in nix-darwin and home-manager, and offer a more complete Nix experience as a configuration/service manager rather than just a package manager on non-NixOS.
Fwiw, you can already have nixos-rebuild read the home-manager configs for all of your users and deploy them as part of the normal NixOS config update process using the included NixOS module.
——
1: https://github.com/svanderburg/nix-processmgmt
In general it is very nice. A common method is you create a `default.nix` file in the project you are working on and use tools that manage the deps for you. For example:
Rust+Cargo: https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d...
Node+NPM: https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9fa...
My only Ruby project is private but I just rolled my own with:
export "GEM_HOME=$out"
In general it is very nice. A common method is you create a `default.nix` file in the project you are working on and use tools that manage the deps for you. For example:
Rust+Cargo: https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d...
Node+NPM: https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9fa...
My only Ruby project is private but I just rolled my own with:
export "GEM_HOME=$out"
I was able to make the switch over cold turkey after ~9 years of ArchLinux.
By sheer happenstance, I blogged earlier this week about one particular killer feature that doesn't get enough air time: https://news.ycombinator.com/item?id=27344677
My not-flake-yet configuration can be found at https://github.com/rraval/nix
>It doesn't work so well for I borrowed my coworker's computer for 5 minutes and want to use my own Vim configuration
You could use something like nixos-shell[1] to spin up a headless VM of your machine into your current shell.
[1]https://github.com/Mic92/nixos-shell
Sure. NPM is the easy case because the package-lock.json file can easily be read by Nix and contains hashes for all of the packages. This means that simply be importing the file into Nix you can have a reproducible build. No Nix-specific maintenance required.
In the linked case I use this library to manage that https://github.com/nmattia/napalm (in that example I use master but for production I would pin a version). It simply parses the package-lock.json, downloads the packages and uses npm to build the node_modules folder. It also provides some convenient functions for building packages with "bin" files or just linking node_modules inside a build.
Note that this is more for project development. It doesn't use the "system" packages (intentionally) for Node, it fetches whatever versions you have specified from NPM. Nix will only provide the "native" stuff like Node and NPM themselves and any native libraries.
Yeah, I’m not sure how up-to-date my knowledge is, but opengl and the like are exceptions to the usual deterministic handling of dependencies on non-NixOS distros, and one has to specify them. It was quite a time I ran nix on a non-nixos distro but there is this tool https://github.com/guibou/nixGL that meant to solve the issue of graphical programs.
It might be possible, but a better approach (and the one Guix used initially, iirc) is to just be compatible with the derivation format (kinda like object files in C/C++ compilation). The end result is basically a big dependency graph, so one may be able to write a different generator in front of it.
Anyone who has done the basics in Prolog could "logically" pull this off (e.g. some rule requires another rule, or however Prolog works; it's been a long time since I looked at it), but all of the extra stuff in the library (e.g. all of the systemd tweaking, interface, etc) is a LOT of man hours.
I heard about Spack [0] on a recent cppcast episode, which seems like a competitor to Nix (but from the supercomputing side of things), but I don't know if they do the OS-level stuff (vs. nix shell / conda / pip / gem replacement stuff).
[0] https://spack.io/
Yes, it's extremely powerful once you truly understand Nix.
There are efforts to improve documentation, but it still is lacking (I think the biggest problem is that Nix is so big, not just the OS but it can be utilized as a build system).
Just with NixOS is not exactly clear how can you for example build your custom image.
I think https://nix.dev/ is approaching the documentation from the right direction.
There are also many pieces that people built that you need to find.
For example some things that I found accidentally:
* https://github.com/matthewbauer/nix-bundle
* https://github.com/cleverca22/not-os
Unfortunately those side projects often have even worse documentation.
nixpkgs is of a very similar size to the aur, but is significantly more up to date: https://repology.org/
A teeny-tiny orientation for (prospective?) Nix newcomers:
Having spent years on Arch and Gentoo, imo the NixOS community is outstanding even among 'advanced' Linux distros in terms of expertise and kindness.
I'll never forget one time I was having problems with a Python package generation tool and when I mentioned it on IRC, and one of its authors (Rok Garbas, who is so quite active in the community) just hopped on a call to debug the issue I was having right then and there.
If you're on the fence about Nix and that kind of community is valuable to you, make sure to check out the forums [1] and realtime chat [2] (the latter of which is unfortunately still in the process [3] of migrating away from Freenode).
If personal assistance/mentorship of the kind I described at the beginning of this post is appealing to you, several generous and knowledgeable community members host Nix ‘office hours’ [4]. I'm not sure who all are still running them, but I know tomberek is for sure [5] and you can find a link in the footnotes.
There is one serious problem with NixOS and the wider ecosystem right now, namely that the best experience available depends on Nix features that are unreleased. Nix makes it very easy to run bleeding edge builds of Nix and enable these features, but the unofficial status of it all has slowed adoption, integration, and documentation of these tools in the wider community.
That aside— i.e., if you're willing to be a little bit of a pioneer— the community is on the whole pretty rich with good documentation of everything but the bleeding edge, unreleased bits at this point. Those pieces mostly impact the CLI and specifying inputs to the expressions you use to define your system. Everything in the NixOS and Nixpkgs manuals is still accurate. The unreleased components are also fairly mature despite their unofficial status: many folks in the community have been using them for a year or two now.
Finally: if you're interested in dipping your toes in without committing to a system fully managed by Nix and you're a macOS user, nix-darwin [6] provides a pretty NixOS-like experience using a module system and CLI based on NixOS'. There's nothing equally complete in terms of managing system services in a declarative fashion on non-NixOS Linux, but home-manager [7] provides some functionality for enabling user-mode services in a declarative style.
You can check whether your favorite software is packaged for Nix here [8], and additionally NixOS does support several other forms of cross-distro packaging/deployment, including Flatpak, Snap, AppImage, and Docker. Steam support is native and works without much fuss, too.
---------
1: https://discourse.nixos.org/
2: https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org
3: https://github.com/NixOS/rfcs/pull/94
4: https://discourse.nixos.org/search?q=office%20hours
5: https://discourse.nixos.org/t/nix-office-hours/11945
6: https://github.com/LnL7/nix-darwin
7: https://github.com/nix-community/home-manager
8: https://search.nixos.org/packages
A teeny-tiny orientation for (prospective?) Nix newcomers:
Having spent years on Arch and Gentoo, imo the NixOS community is outstanding even among 'advanced' Linux distros in terms of expertise and kindness.
I'll never forget one time I was having problems with a Python package generation tool and when I mentioned it on IRC, and one of its authors (Rok Garbas, who is so quite active in the community) just hopped on a call to debug the issue I was having right then and there.
If you're on the fence about Nix and that kind of community is valuable to you, make sure to check out the forums [1] and realtime chat [2] (the latter of which is unfortunately still in the process [3] of migrating away from Freenode).
If personal assistance/mentorship of the kind I described at the beginning of this post is appealing to you, several generous and knowledgeable community members host Nix ‘office hours’ [4]. I'm not sure who all are still running them, but I know tomberek is for sure [5] and you can find a link in the footnotes.
There is one serious problem with NixOS and the wider ecosystem right now, namely that the best experience available depends on Nix features that are unreleased. Nix makes it very easy to run bleeding edge builds of Nix and enable these features, but the unofficial status of it all has slowed adoption, integration, and documentation of these tools in the wider community.
That aside— i.e., if you're willing to be a little bit of a pioneer— the community is on the whole pretty rich with good documentation of everything but the bleeding edge, unreleased bits at this point. Those pieces mostly impact the CLI and specifying inputs to the expressions you use to define your system. Everything in the NixOS and Nixpkgs manuals is still accurate. The unreleased components are also fairly mature despite their unofficial status: many folks in the community have been using them for a year or two now.
Finally: if you're interested in dipping your toes in without committing to a system fully managed by Nix and you're a macOS user, nix-darwin [6] provides a pretty NixOS-like experience using a module system and CLI based on NixOS'. There's nothing equally complete in terms of managing system services in a declarative fashion on non-NixOS Linux, but home-manager [7] provides some functionality for enabling user-mode services in a declarative style.
You can check whether your favorite software is packaged for Nix here [8], and additionally NixOS does support several other forms of cross-distro packaging/deployment, including Flatpak, Snap, AppImage, and Docker. Steam support is native and works without much fuss, too.
---------
1: https://discourse.nixos.org/
2: https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org
3: https://github.com/NixOS/rfcs/pull/94
4: https://discourse.nixos.org/search?q=office%20hours
5: https://discourse.nixos.org/t/nix-office-hours/11945
6: https://github.com/LnL7/nix-darwin
7: https://github.com/nix-community/home-manager
8: https://search.nixos.org/packages
If you don't mind the storage penalty, it looks pretty convenient to set up an Arch Linux chroot and use packages from the AUR when you need to: https://github.com/lemniskett/archbox/blob/master/NIXOS_INST...
Nixpkgs itself is several times the size of the base Arch Linux package collection, and by ‘non-unique’ package count, Nixpkgs is also much larger than the AUR. In addition to Nixpkgs, you can find Nix packages in several community ‘overlays’ for Nixpkgs as well as Nix's own user repositories.
You can check to see whether everything you currently use/need is conveniently available for NixOS in a comprehensive-ish way through the combination of these two web search tools:
• for Nixpkgs/NixOS: https://search.nixos.org/packages?channel=21.05
• for NUR: https://nur.nix-community.org/
NixOS also includes native Flatpak support.
Fwiw, packaging most things for Nix is very easy. I left Arch in ~2010 because at the time the package management stack and default repos on Arch basically sucked compared to most distros I'd used and liked, and from then on I decided that if I wanted software that wasn't in my distro's repos I'd just package it myself. After taking a little time to learn the tools on whatever distro I was using, I never missed Arch or the AUR. Compared to other distros, packaging normal software from source is usually exceptionally easy on NixOS.
If I were you I'd just dive right in and hit Nix's channel on Matrix with the Nixpkgs manual in hand if I found something I wanted to use that wasn't already packaged. But you can fall back on the options outlined above.
If you don't mind the storage penalty, it looks pretty convenient to set up an Arch Linux chroot and use packages from the AUR when you need to: https://github.com/lemniskett/archbox/blob/master/NIXOS_INST...
Nixpkgs itself is several times the size of the base Arch Linux package collection, and by ‘non-unique’ package count, Nixpkgs is also much larger than the AUR. In addition to Nixpkgs, you can find Nix packages in several community ‘overlays’ for Nixpkgs as well as Nix's own user repositories.
You can check to see whether everything you currently use/need is conveniently available for NixOS in a comprehensive-ish way through the combination of these two web search tools:
• for Nixpkgs/NixOS: https://search.nixos.org/packages?channel=21.05
• for NUR: https://nur.nix-community.org/
NixOS also includes native Flatpak support.
Fwiw, packaging most things for Nix is very easy. I left Arch in ~2010 because at the time the package management stack and default repos on Arch basically sucked compared to most distros I'd used and liked, and from then on I decided that if I wanted software that wasn't in my distro's repos I'd just package it myself. After taking a little time to learn the tools on whatever distro I was using, I never missed Arch or the AUR. Compared to other distros, packaging normal software from source is usually exceptionally easy on NixOS.
If I were you I'd just dive right in and hit Nix's channel on Matrix with the Nixpkgs manual in hand if I found something I wanted to use that wasn't already packaged. But you can fall back on the options outlined above.
Given that you already have flakeified everything, it's not that hard to pull in a different version of nixpkgs and cherry-pick packages from it. I have a (somewhat complex) setup utilizing this: https://github.com/casept/nixos-config
I run [nix-update](https://github.com/Mic92/nix-update/) to update stuff. If you want to package something new, first identify the programming language/buildsystem the project is using and than look for a similar project in nixpkgs.
and then you can add, e.g., `nix-processmgmt-tools.common` to your `environment.systemPackages`.
I think maybe the reason instructions aren't given for some projects is that they see those parts of the guide as mostly for beginners, and they expect advanced users to just figure it out. In the case of nix-processmgmt, I think Sander doesn't actually expect to have any users! In the latter case, an imperative install that users are expected to play with for a little while and then just throw away is supposed to be enough.
You're right, though, that it's odd and disappointing that instructions for the preferred way of doing things are sometimes simply not given. A polite pull request or issue report would probably be well-received. My recommended strategy, if you get stuck, would be to ask for help getting those packages into scope declaratively on Discourse or Matrix, and then to offer the authors of these out-of-tree packages pull requests to modify their READMEs accordingly. :)
—
1: https://github.com/gytis-ivaskevicius/flake-utils-plus
2: https://github.com/nix-community/emacs-overlay#quickstart
3: https://github.com/nix-community/home-manager/blob/master/ov...
4: https://github.com/nix-community/home-manager/blob/master/de...
and then you can add, e.g., `nix-processmgmt-tools.common` to your `environment.systemPackages`.
I think maybe the reason instructions aren't given for some projects is that they see those parts of the guide as mostly for beginners, and they expect advanced users to just figure it out. In the case of nix-processmgmt, I think Sander doesn't actually expect to have any users! In the latter case, an imperative install that users are expected to play with for a little while and then just throw away is supposed to be enough.
You're right, though, that it's odd and disappointing that instructions for the preferred way of doing things are sometimes simply not given. A polite pull request or issue report would probably be well-received. My recommended strategy, if you get stuck, would be to ask for help getting those packages into scope declaratively on Discourse or Matrix, and then to offer the authors of these out-of-tree packages pull requests to modify their READMEs accordingly. :)
—
1: https://github.com/gytis-ivaskevicius/flake-utils-plus
2: https://github.com/nix-community/emacs-overlay#quickstart
3: https://github.com/nix-community/home-manager/blob/master/ov...
4: https://github.com/nix-community/home-manager/blob/master/de...
You can use the Nix tooling to show the diff between two derivations' closure.
I have a script which I use [1] after updating my Flakes to do just that : know what has been upgraded.
[1] https://github.com/nix-community/nur-combined/tree/master/re...
I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1].
[1] https://github.com/Shopify/runix/