Our great sponsors
-
-
-
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.
-
impermanence
Modules to help you handle persistent state on systems with ephemeral root storage [maintainer=@talyz]
-
awesome-nix
😎 A curated list of the best resources in the Nix community [maintainer=@cyntheticfox]
-
-
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.
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Great introduction and overview on the theoretic foundations of the nix ecosystem!
For people new to it, I am trying to provide a quick glossary of terms here, as I understand them after about 2 years of using nix.
* nix: a language to create derivations and the interpreter/package-manager which provides the implementation of said language. It currently offers two command-line interfaces, the stable on with hyphenated commands like "nix-build", "nix-shell", etc. And the newer, "experimental" one which includes support for nix flakes and so on, without hyphens: nix build, nix shell, nix run, etc.
repo: https://github.com/nixos/nix
Nix is an abstraction around `tar -xf && make && make install`. In fact, those commands are even executed by nix, just in a sterile reproducible environment.
What sets nix apart from other package managers is that you are never running `make install` on your root filesystem, but `make` can still dynamically link to libraries (that also aren't installed on the root filesystem) without editing the Makefile directly to find them.
This way, you can't break existing packages, you can trivially roll back changes (because updates are new instances), and you can always start over fresh.
The only problem is that you have to wrap every package in a derivation, then publish that derivation somewhere. Right now, all derivations are tracked in a single git repo (with dozens of branches), all coordinated over GitHub Issues, and referenced by nix itself by an arbitrary (versionless) name in a global namespace in this file: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
That last bit can be avoided by using pinning and flakes, but it's still the default way to use nixpkgs, and documentation doesn't clarify much or offer a better consistent UX paradigm.
docs nixos: https://nixos.org/manual/nixos/stable/
This tooling includes higher-level helpers for language-/environment-specific packaging, like "buildGoModule", "buildRustPackage" and so on, as well as e.g. tooling to run integration tests in a whole cluster of inter-connected linux VMs!
Packages which are submitted to nixpkgs must fulfill certain criteria, such as not using "IFD" (input-from-derivation, to simplify: "letting nix evaluate nix-code which was generated by another deriviation/"nix package".
nixpkgs is alive and well with lots of daily contribution and an everlasting effort to keep Hydra, the nix-specific CI/CD system and public binary caches up to date and responsive. Thanks to all maintainers & contributors!
* flakes are an approach to standardize a way to package nix code outside of nixpkgs but to still keep it re-usable. They are still "experimental" as the details are figured out, but nevertheless used in production. There are some frame-works to keep boilerplate low, like "flake-utils", "flake-parts" and others, as well as e.g. deployment tools like "colmena" and "deploy-rs" and re-usable helpers for system-configuration like e.g. https://github.com/nix-community/impermanence
There's lots of other stuff in the community, things like home-manager, direnv + flakes and devshells changed my workflow fundamentally to the better since I've switched. If you got the time and are still interested, join us on matrix or elsewhere :)
Nix seems great for build servers. This is a great introduction to the motivations behind it.
I'm not sold on using it for managing developer environments (another use case it is often used for). It "solves" the problem that developers might be using different versions of libraries or compilers on their machines... but it comes at the cost of having to learn a whole new programming language, a configuration language, a whole new jargon, and workflow. It's a bit like using Docker as a development environment. It introduces a non-trivial amount of friction.
Some folks get excited about package management and configuration. Personally I don't care for it enough to over-come such a high learning curve. And I don't particularly like the workflow it enforces.
However it is pretty great for reproducible CI/CD systems like Hydra: https://github.com/NixOS/hydra
Depending on your specific needs, the channelsConfig (modify arguments passed to Nixpkgs) and overlay tooling in flake-utils-plus may be adequate: https://github.com/gytis-ivaskevicius/flake-utils-plus/tree/...
Nvidia works excellent in my experience, Nix provides the best Wayland/Nvidia experience I've had out of any distro. I'm using a 3070ti, but you should be able to steal most of my configuration if you want a similar setup: https://github.com/toasterrepairman/boostrap/blob/main/nix/n...
There are some sifferent/new tools for adding your own Python packages these days. It's still not truly solved, but one of these new package generation tools might serve your better:
poetry2nix: https://github.com/nix-community/poetry2nix
dream2nix: https://nix-community.github.io/dream2nix/guides/getting-sta...
mach-nix: https://github.com/DavHau/mach-nix
pip2nix: https://github.com/nix-community/pip2nix
pynixify: https://github.com/cript0nauta/pynixify
The tools available to you at the time (pypi2nix and maybe python2nix, if it was a long time ago) have been abandoned in favor of the newer tools, I think chiefly poetry2nix but I'm not sure.
There's still the Nixpkgs buildPythonPackage stuff, I think, if your goal is to upstream a lib into Nixpkgs. But if you just want to build your own Python applications and vendorize the deps (e.g., for work), you might try one of the tools above, which weren't available 3+ years ago. Maybe Nixy Python users and developers can reply with some of their experiences using those tools :)
There are some sifferent/new tools for adding your own Python packages these days. It's still not truly solved, but one of these new package generation tools might serve your better:
poetry2nix: https://github.com/nix-community/poetry2nix
dream2nix: https://nix-community.github.io/dream2nix/guides/getting-sta...
mach-nix: https://github.com/DavHau/mach-nix
pip2nix: https://github.com/nix-community/pip2nix
pynixify: https://github.com/cript0nauta/pynixify
The tools available to you at the time (pypi2nix and maybe python2nix, if it was a long time ago) have been abandoned in favor of the newer tools, I think chiefly poetry2nix but I'm not sure.
There's still the Nixpkgs buildPythonPackage stuff, I think, if your goal is to upstream a lib into Nixpkgs. But if you just want to build your own Python applications and vendorize the deps (e.g., for work), you might try one of the tools above, which weren't available 3+ years ago. Maybe Nixy Python users and developers can reply with some of their experiences using those tools :)
There are some sifferent/new tools for adding your own Python packages these days. It's still not truly solved, but one of these new package generation tools might serve your better:
poetry2nix: https://github.com/nix-community/poetry2nix
dream2nix: https://nix-community.github.io/dream2nix/guides/getting-sta...
mach-nix: https://github.com/DavHau/mach-nix
pip2nix: https://github.com/nix-community/pip2nix
pynixify: https://github.com/cript0nauta/pynixify
The tools available to you at the time (pypi2nix and maybe python2nix, if it was a long time ago) have been abandoned in favor of the newer tools, I think chiefly poetry2nix but I'm not sure.
There's still the Nixpkgs buildPythonPackage stuff, I think, if your goal is to upstream a lib into Nixpkgs. But if you just want to build your own Python applications and vendorize the deps (e.g., for work), you might try one of the tools above, which weren't available 3+ years ago. Maybe Nixy Python users and developers can reply with some of their experiences using those tools :)
There are some sifferent/new tools for adding your own Python packages these days. It's still not truly solved, but one of these new package generation tools might serve your better:
poetry2nix: https://github.com/nix-community/poetry2nix
dream2nix: https://nix-community.github.io/dream2nix/guides/getting-sta...
mach-nix: https://github.com/DavHau/mach-nix
pip2nix: https://github.com/nix-community/pip2nix
pynixify: https://github.com/cript0nauta/pynixify
The tools available to you at the time (pypi2nix and maybe python2nix, if it was a long time ago) have been abandoned in favor of the newer tools, I think chiefly poetry2nix but I'm not sure.
There's still the Nixpkgs buildPythonPackage stuff, I think, if your goal is to upstream a lib into Nixpkgs. But if you just want to build your own Python applications and vendorize the deps (e.g., for work), you might try one of the tools above, which weren't available 3+ years ago. Maybe Nixy Python users and developers can reply with some of their experiences using those tools :)
Yeah, if you use a module system like Nix-Darwin or Home Manager: https://github.com/nix-community/home-manager/issues/1341#is...
(Hopefully comparable modules are on their way onto the defaults for each of those module systems)
> To me it looks like Nix is firmly headed in the direction of a yet another tool with a very good idea whose authors don't want to make it more usable and thus it remained a niche curiosity for people with too much free time.
What gives you the indication things are headed in the wrong way?
I think things are heading in the right direction.
The last year has seen nix flakes release to the stable nix version. Flakes are a big UX improvement to Nix.
The last few releases of nix have added improved support for debugging nix code. (Poor debugging UX was highlighted as a major pain point).
Efforts from major contributors are acknowledging the importance of improving documentation. - From the latest community survey, the steep learning curve and poor onboarding experience was noted as a major pain point. etc.
> even looks down on busy programmers who want to memorize a few shorthands and move on
Ehhh.
I don't think it's fair to say "vim is a bad tool because it requires learning to get used to it". -- Fortunately, developers aren't stuck between nano and vi, they've got highly accessible tools like VSCode.. or on the command line, even micro https://github.com/zyedidia/micro
Deploy-rs is a great alternative. It works as wrapper on top of flakes, local (optionally, cross-) building and copying closures to target machine with activation:
https://github.com/serokell/deploy-rs
Are any of your R users TMB users? Because I ran into that in multiple setups (Guix SD and Guix on foreign distros) where only a specific ordering worked even when using guix shell --pure. This was back in the R 4.1.2 days. In theory it should be impossible and yet I ran into it. No I was not mixing packages installed via. install.packages.
Right now with the latest version of Guix and R 4.2.1 TMB is not usable. Try running:
"guix shell --container r r-tmb make gcc-toolchain gfortran-toolchain"
then try running the linreg.R (with the corresponding cpp file, or any of the examples) example from https://github.com/kaskr/adcomp/tree/master/tmb_examples