how to use on nixos?

[srghma]

[stefan-hoeck]

Sorry, I am not a Nix user so I can't help with this one. Maybe someone else can step in here?

[buzden]

@mattpolzin and @DanMax03 might help, as to my knowledge they are NixOS users

[mattpolzin]

The question is a bit vague for me to know exactly what the end goals are, but there are several potential answers depending on those goals.

If you want to have Pack installed on your machine much like it would be on a non-nixos machine, you are going to want to install the following via your system config: idris2, gcc, and gmp. Then follow the Pack install instructions. I have not done this so you might hit a snag but nothing should stop you from doing it this way so any snag should be small.

If you want to install Pack via a Nix derivation but otherwise use Pack as any other Pack user would to build your Idris2 programs, feel free to snag the derivation I wrote (has not been merged into nixpkgs yet): https://github.com/NixOS/nixpkgs/pull/344109/files

If you want to go full nix on things (i.e. minimize the amount of stuff built & stored in your home folders and maximize the amount of stuff configured via Nix files), you can check out nix-idris2-packages which does not use Pack as its frontend but it pulls the exact same database of Idris2 packages in as Pack uses and enables you to use the buildIdris family of Nix functions to build your projects.

[EDIT] I added gcc to the list of installs you should do via system config if you are going with the first option I mentioned.

[DanMax03]

As Mathew said, there is a giant issue in nix community regarding other ecosystems: should they be totally wrapped in nix or not?

Depending on that, you may search for 2 possible solutions:

1. nix package(s) that allow to configure every single pack's package for idris2 via nix config
2. nix package(s) that allow you to install pack and control every folder that it needs, though managing pack's packages is done completely by pack itself

For the first option, I've heard about idr2nix and it seems to be quite fresh and rolling. The second option doesn't have a solution... yet

Mathew also mentioned that you may try to mix NixOS with pack installed in an old-fashioned way, but then you will face several issues:

• It probably won't work as soon as NixOS doesn't follow FHS standard. Some applications depend on dynamic system libraries and the fact that a casual Linux distribution puts them in their standard paths
• Why to use NixOS at all if you do such things? Maybe it's better to switch to something less rigid like Arch?

Currently, I don't have time to dive into nix (I use NixOS less than a year) and I am not using flakes, so I decided to make a docker container with Idris 2. Works perfectly for me, especially the ability to get a fresh version of any idris package without additional actions

[mattpolzin]

Just a small update: it's been a bit now since pack was made available as a package in nixpkgs. It can be installed in the normal way under NixOS now. The only caveat is that pack's auto updating (updating the pack program itself) won't work; this is antithetical to having nix manage the pack installation anyway. Everything else should work just fine.

[jgarte]

should they be totally wrapped in nix or not?

I have the same questions for Guix, which I use more often than Nix. Maybe the recentish approach below with Rust provides some food for thought if pack is moving towards operating like cargo?

https://guix.gnu.org/en/blog/2025/a-new-rust-packaging-model/

[mattpolzin]

Interesting. But if you’re using the pack database (via the pack executable or, for example, my idris2Packages pack collection), then the mismatch the article refers to does not exist. All packages use all other packages at the current set versions which means you do benefit from building dependencies as their own derivations because they can be reused by other dependencies and the whole lot of them can be hosted in a binary cache so build times of any number of end-user executables can all benefit from the shared dependency builds. This only works if the disparate executables are using the same version of the package set, but it works well in that case.

I don’t know much about rust, but I think it only does whole program compilation which is the other reason building dependencies individually may not have made sense. The fact that Idris will compile to TTC and then reuse that intermediate down the road differentiates it because it does benefit us to build each dependency ahead of time.