Support [experimental] flakes

[philipp-baumann]

just to list; somewhen in future when we are bored and done with backbone of {rix}

[philipp-baumann]

@b-rodrigues I am currently exploring devbox get some more recent nix package versions for specific software (e.g. need to have up to date quarto for certain extensions, which really quick to get via this approach.

I really like this in combination with nixhub.io https://www.jetpack.io/devbox/docs/quickstart/

https://www.jetpack.io/blog/using-nix-flakes-with-devbox/

[b-rodrigues]

There's also this: https://devenv.sh/

several things that we could explore!

[Kupac]

When I started my Nix journey, I decided to follow the flake path from the beginning. So naturally, when I found out about rix, I immediately started thinking how to have a flake-enabled version of it.

It could be an option with flake = FALSE by default.

I can see two ways to make this happen.

1. create a basic flake.nix, which would import default.nix. That's the most straight forward implementation. Currently, this is not possible, because fetchTarball doesn't specify a hash, and this is required by flake, to be able to create a lock file. I think it would be good practice anyway to not only pass a url, but also a hash. (example here)

2. The other option is to create a nice, editable flake.nix file, or even a multifile structure, which is more readable and editable. Of course, the functions used to build default.nix should be re-used as much as possible. This could reduce the burden of having to maintain a no-flake and a flake output of rix.

Which way would you prefer?

[b-rodrigues]

The thing I'm still wondering is what use case flakes solve/make easier than the current setup? I'm not necessarily against support flakes per se, but I'd like to know what I'm missing. I'm not necessarily convinced that flakes are a useful abstraction for development envs. What am I missing?

[Kupac]

Here's a summary in case you haven't read it: https://www.tweag.io/blog/2020-05-25-flakes/#what-problems-do-flakes-solve

For example, we could define an environment with whatever packages, and ship all the IDEs in a single flake. You could choose which one is the default. We could also ship docker container artifacts, which one could build in case you want to share your env with non nix users. There are many possibilities

[Kupac]

I started a nix project like that, but rix is a better approach for R users, who don't know nix yet.

[b-rodrigues]

What do you think would be the impact on the current codebase of supporting flakes? Seems like option 2 would be the best, and also still have minimal impact?

[Kupac]

I'm not familiar enough with the code base to be able to fully grasp the impact. But I think we can work with the current functions, and perhaps write a few more. Probably we'll need a dependency on gitr, because flakes only see files that are tracked by git. I also wonder whether it would make sense to wrap some of the functionality of nix into R functions. I'm thinking nix flake update nix flake init, nix show-config etc. This would add a system dependency on nix.

I think of creating a flake template somewhere in inst/. That template would import a few local nix files, genereated by rix, which contain the packages in the environment. Alternatively, we can generate a single flake.nix file from scratch, like we do for default.nix.

[b-rodrigues]

Composing environments does sound appealing , especially having one for packages and another for IDEs 🤔

Feel free to hack it together 😁

[philipp-baumann]

I'm not familiar enough with the code base to be able to fully grasp the impact. But I think we can work with the current functions, and perhaps write a few more. Probably we'll need a dependency on gitr, because flakes only see files that are tracked by git. I also wonder whether it would make sense to wrap some of the functionality of nix into R functions. I'm thinking nix flake update nix flake init, nix show-config etc. This would add a system dependency on nix.

I think of creating a flake template somewhere in inst/. That template would import a few local nix files, genereated by rix, which contain the packages in the environment. Alternatively, we can generate a single flake.nix file from scratch, like we do for default.nix.

I am in favor of option 2 of implementing it. We can get both, separation of concerns but also reuse the existing function stack for boilerplating. @Kupac I'm sure there is still parts in the traditional way that we can function up more efficiently for both default channels and flake ways. We can follow the approach we used for nix-build in nix_build() also for nix flake ... commands, invoke them via sys::exec_background() (async, non-blocking) and sys::exec_internal (blocking) like here: https://github.com/b-rodrigues/rix/blob/fe4d98eddd5f190d97ee9a7821d8d49750eff2a0/R/nix_build.R#L89-L93

We should definitively default for channels, but why not add flakes for those who want/need them. Regarding the need of gitr: does look quite nice, but I'd be hesistant adding another strict dependency to the list because it is a reproducibility package. We could also use requireNamespace() and check like that if it is installed. If its just git add, commit, and push we needs it's easy to just follow a system2() or sys:: wrapper approach, like gitr does, so just a few lines of code more to add to the package.

[Kupac]

FYI, I started to read the code base, and think about how to actually do this flake thing. Thanks for the pointers above, I agree 100%, and there are some good ideas in there.