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.
-
-
-
-
-
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.
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt
This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself from version "nix-2.3.10" to "nix-2.3.10-x86_64-unknown-linux-musl" because it saw that package's version string as a version bump. The suggestion in the github issue was to instead use an unofficial third party package for basic package management.
https://github.com/NixOS/nixpkgs/issues/118481
The experience came across as a massive red flag and I decided not to pursue it further.
I am very much looking forward to trying Nix I just haven’t made the time.
That being said the article jogged my memory on some related thoughts...
If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/
If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ It uses pyenv under the hood for Python management AFAIK.
I am very much looking forward to trying Nix I just haven’t made the time.
That being said the article jogged my memory on some related thoughts...
If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/
If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ It uses pyenv under the hood for Python management AFAIK.
> Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.
Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine.
You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code.
Put those tools in your systemd service before launching your app, and you're good to go.
(NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I won't be able to see the final picture.)
[1]: https://github.com/channable/vaultenv
We're using Nix packages at Precision Nutrition to manage our dev environments: https://github.com/PrecisionNutrition/pndev/. It's been enormously successful. I highly recommend it.
I found useful this series of articles introducing Nix by using it with Haskell: https://github.com/Gabriel439/haskell-nix
I hope it helps.
Thanks for the response!
> This is difficult to answer without knowing more details.
The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files:
https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm...
The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what the dependencies are.
Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi...
Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to users and any system which required everyone to leave behind these existing workflows would be an immediate non-starter.
I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build packages as usual with colcon, the usual workspace-building tool, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well.
[1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay
Thanks for the response!
> This is difficult to answer without knowing more details.
The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files:
https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm...
The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what the dependencies are.
Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi...
Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to users and any system which required everyone to leave behind these existing workflows would be an immediate non-starter.
I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build packages as usual with colcon, the usual workspace-building tool, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well.
[1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay
Thanks for the response!
> This is difficult to answer without knowing more details.
The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files:
https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm...
The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what the dependencies are.
Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi...
Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to users and any system which required everyone to leave behind these existing workflows would be an immediate non-starter.
I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build packages as usual with colcon, the usual workspace-building tool, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well.
[1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay
Thanks for the response!
> This is difficult to answer without knowing more details.
The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files:
https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm...
The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what the dependencies are.
Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi...
Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to users and any system which required everyone to leave behind these existing workflows would be an immediate non-starter.
I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build packages as usual with colcon, the usual workspace-building tool, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well.
[1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay
A few days ago, I came across RobotNix[0] which uses Nix to deterministically build custom Android images. Since I really want to adapt Android to my needs but have always struggled with building Android on my own (what a shitty and complicated build system), I'm now very inclined to learn Nix. I'm not sure I like the syntax but hopefully I'll get used to it.
Another reason I'm quite excited about Nix is that in my team we're currently using a whole bunch of tools like pip, Conda, npm all at the same time to manage our dependencies and it's starting to become really cumbersome to set up the dev and production environments correctly across operating systems and platforms. For instance, Conda doesn't exist on arm64, lots of pip packages have to be compiled by hand on arm64 etc. etc. It's a mess that I'd love to get rid of.
[0]: https://github.com/danielfullmer/robotnix/
I wrote a language tutorial for only the language a while back, and have gotten the feedback that it has helped a lot of people - maybe it'd clear something up for you: https://github.com/tazjin/nix-1p
I think [Nickel][1] aims to add static types to Nix, but I don't know of any efforts to integrate Nickel into nixpkgs.
[1]: https://github.com/tweag/nickel
Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.
I don't want to be too critical, I love Nix. But the experimental new UI was already in development (and available) when I started using Nix in 2018. It has also changed quite a lot recently and is now very strongly tied to flakes. However, the flakes RFC was withdrawn [1]. Given that flakes are a large change, I'd expect (but maybe I am wrong) that there will be a new RFC.
At any rate, I would be surprised if the new CLI with flakes are close to release.
[1] https://github.com/NixOS/rfcs/pull/49
Yep. The advantage of `with` is that we're dealing with first-class values (attribute sets, like `{ foo = "bar"; }`), rather than an implicit environment/context. My rationale is at https://github.com/NixOS/nix/issues/1361#issuecomment-390420...
The thing about shadowing is that `with` will not shadow anything that's in the implicit context, which includes things defined by `let` (hence why I avoid it) and function arguments (unavoidable). We can shadow other `with` bindings as much as we like, e.g.
with { foo = 1; };
https://github.com/pwm/nix-home
The readme was/is more of a short note to myself than for users, nevertheless this is how i manage my entire home env on my mac and it works beautifully.
I did a month, diving directly into the deep end with flakes and all. I don't know, it really is hard in the beginning. Like, really hard. But eventually I got myself a setup I could use in my two laptops and workstation. A setup, that sets my home directory, all my programs and my custom desktop just the way I want. Everything is in the github repo, and installing with the flake will give me the exact experience I have in my other machines.
I tend to use lots of custom tools and commands, that are really painful to install and setup for a new machine. With NixOS all of it is just one command away.
But, I agree, it is REALLY HARD in the beginning to grasp things.
Here's my configs if you want to see how I approached my own setup: https://github.com/pimeys/nixos