Call for participation: Nix workshop at VandyHacks

Events
1

This year at VandyHacks I’ll be hosting a Nix workshop on Friday (2021-10-08) 9 to 10 pm central U.S. time (UTC-6). The workshop is intended for people with no prior Nix experience but who inevitably have run into a myriad of dependency and developer environment issues. We’ll also demonstrate more advanced topics such as cross-compilation. All are welcome to attend!

You can watch online via Twitch.

EDIT: It will also be recorded, I’ll post a link to the video in this thread.

6 Likes
2

Here is the link to the twitch video (starts at around 3’) :
https://www.twitch.tv/videos/1171499889

Thank you @siraben !

4 Likes
3

Couple of questions:
1- You mentioned Robotic Operating System but as far as I know, the package is not in nixpkgs. There is a third-party overlay but it has about 80% of the official ROS packages. So what is the recommended way of having ROS or ROS2 in NixOS?

2- You mentioned how to do cross-compilation for an Arm target. I wonder, is it possible to “run” a binary which was compiled for a foreign target architecture? Like, is it possible to execute an Arm binary in a x86-64 system?

3- Can’t we incorporate .envrc inside shell.nix so all project config settings and vars would be in a single place? If it is possible, is it recommended to do so?

4

To my knowledge, the overlay seems to be the most complete way to do it currently, but at some point in the future my co-presenter and I might take on porting ROS packages in Nixpkgs for macOS and Linux.

Yes, NixOS has support for emulation via QEMU. You can also add boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; to your configuration.nix, see this for details.

Sure, if you need to set environment variables you could do it all in a shell.nix. .envrc is just needed for direnv to automatically reload your environment/you may want to store secrets in it instead of shell.nix.

1 Like
5

Thanks for your answers!

envrc is just needed for direnv to automatically reload your environment

But if we use lorri it also reloads the env if shell.nix changes, right? It seems to me .envrc is completely redundant in Nix context if we use lorri but is needed in non-nix distros where direnv is used.

Speaking of secrets, suppose we need an API_KEY to do some REST requests. Where should we put the secret?

  • If we use an env var, it would be accessible from other processes in the same shell => Insecure
  • If we use a file with special privileges, the consumer scripts/programs should also have elevated privileges => Inconvenient
6

direnv on its own also reloads the env if shell.nix changes, and looks like lorri still needs .envrc in the repo, according to the readme.

I’m not sure about the best approach to secrets management, for me it’s mostly been using .envrc and keeping it out of version control. YMMV

1 Like