Hacker News Reader

Comment by goosedragons | Hacker News Reader

I recently tried Guix which is somewhat similar to Nix in theory. While I loved the idea I did not love dealing with cryptic problems resulting from it. For example I ran into an issue where one R package would only work properly if I installed other packages in a specific order, doing an update though could mess up that order breaking the package. Later updates to R broke support for certain things entirely that I don't see on non-Guix setups either. Plus getting things that required binaries I can't (or easily) compile myself to work is a pain.

I just can't justify fiddling with my package manager so much.

View on HN

This is my experience with both Nix and Guix. They have advantages but they are different to the point of being unusual.

I very much want the benefits of these kinds of systems, but they both produce a run time system (shell environment, whatever) that is not typical of how most people use software. So, while most other people are helping each other out with the "usual" problems, Nix/Guix users have a different set of problems. Sure, they are reproducible problems often shared by all other Nix/Guix users, but those communities are niche compared to what is typical.

I am not sure, but it is possible that R want to be its own package manager which interferes with Guix? A similar problem seems to appear in Python, where there on Distributions like Debian there is kind of a struggle which package manager - the system-defined packages, or the user-defined ones like pip - have the last word.

I have used Guix a bit with Common Lisp libraries, and that works like a charm. I also found it useful to be able to use new Emacs packages like the newest version of Magit, without having to install or supersede the OS installation.

R does have it's own package manager but I was explicitly not using it because I read there could be issues, instead only installing packages through Guix. It was mainly a problem compiling things within R as if the order of how gcc-toolchain and the R package were setup it straight up wouldn't work. With later versions it just broke entirely and I never managed to fix it.

Despite R being the most commonly packaged software on Guix and it being a GNU project and a "common lisp for dummies" lispy language which is used by millions of students, researchers and data scientists, the developers seem to have a noticeable animosity towards it (although not as much as the "snake people"). This makes me sad, as R users would be the first to sign up for what Guix offers if it worked well and the RcppGuile R package could be used as a template for bridging the gap between the spartan scheme infrastructure and the extremely rich and beginner friendly R infrastructure. I feel like this could also help motivate the Guix developers to improve the documentation and guile porcelain interfaces so they could be used directly instead of the copious bash code they all seem to relish writing.

I don't follow. Are you saying that Guix developers have animosity towards R or the other way around? In any case I haven't seen animosity on either side.

FWIW I also wrote guix.install, which lets you install R packages through Guix (whether or not they are available in Guix) from within a running R session. I'm maintaining R packages in Guix and woudl like to see more adoption of Guix among R users, so if you have any recommendations on what pain points there are and how to overcome them I'd be happy to hear them.

I have not experienced that for what it's worth... atleast not after I rebuilt the whole profile.

This… shouldn’t happen. The whole point of Nix and Guix is that you can have multiple versions of the same thing in different dependency chains. It’s designed to avoid precisely this issue. If a package relies on something it should be built before hand, and if and only if it’s identical (well content addressable vs inputs is a whole other thing) it will share the dependency.

Would you mind sharing exactly what the R packages you were having problems with were?

I wonder if you were relying on globally installed versions of things instead of an R installation that had the packages wrapped into its environment. I’m more familiar with Nix, but you’ll typically see people do something like add this to a local project build input or development shell:

    r-lang.withPackages with rPackages; [ r-ggplot2 r-data-table ];

Rather than

    nix-env -iA r-4.2 r-ggplot2 r-data-table

Or the Guix equivalent

    guix install r …

Globally installing things can lead to situations where you think it should work but if you really think about how the store dependencies work, they don’t.

Yeah and that's part of what made it so confusing.

Even in a pure Guix shell it only worked in a specific order. Packages were R, TMB (an R package), gcc-toolchain, gfortran-toolchain and make. You need to be able to compile C++. If was R specified before the toolchains then nothing could be compiled with TMB. I forget the exact error. I did not have those packages globally installed and I saw the same problems with Guix SD and a foreign distros.

But with R 4.2 I ran into a different problem and never fixed, that anything using the RcppEigen header would not compile.

And I don't believe Guix has the same wrapping packages into R style as Nix.

I was too frustrated by the insistence on libre purity by the main Guix channels, even if I think it is superior software, so I switched to Nix (and actually went fully NixOS after a month or so).

I had R package compilation issues on 4.2 as well, but I also had them on my Windows work machine. I'll try to test things out and see if I can figure out if it's still an issue.

That sounds like a dependency not detected by the kludge that at least Nix uses where it essentially greps everything for path names that look like dependencies.

Said differently:

- build recipes A and B add paths to the store

- B uses paths from A, but in a way that the dependency tracker does not notice

- if the paths from A were instantiated in the system first, B works by luck

I'm maintaining most of the R packages in Guix and helping hundreds of users at a research institute with their R stuff. I haven't seen any problems like that.

The order of installation does not (and cannot) matter. The most common problem I've seen is that people mix packages from Guix with those built with install.packages that have been linked with incompatible system libraries, which cannot possibly work. This problem is easily avoided --- either by using a container shell (guix shell -C) with a separate toolchain (not the system's toolchain) or by not using `install.packages` (e.g. use `guix.install` instead).

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 and you'll run into "did you mean 'bad_array_new_length'? This is on a Guix SD system too...

And you have to specify make,gcc-toolchain and gfortran-toolchain for it to work normally. If you leave out gfortran-toolchain it compiles but you can't load it and it doesn't work without make. Previously I had it working with those 5 packages in a specific order.

Perhaps this is a TMB only problem but it's a giant PITA when it works fine on non-Guix setups.

Thanks for the details.

I noticed that gcc-toolchain and gfortran-toolchain are mismatched: the former is at version 12 while the latter is at version 10. (Someone must have forgotten to update gfortran when they updated gcc-toolchain.)

I get no errors when using this environment:

    guix shell --container r-minimal r-tmb coreutils make gcc-toolchain@10 gfortran-toolchain@10

(Feel free to send future problem reports to bug-guix@gnu.org.)

I would be very happy to see details on your R problems, as I have never encountered anything like that in the many years I have been packaging R things for Guix and supporting R users at the research institute where I work.

I mean if you don't want to fiddle with it I really don't get why you would choose Guix to test drive this way of managing your packages. It's the way less mature and less supported Nix.

I did try Nix briefly. It was even more confusing to configure for use with R IMO.

Not when it comes to R. I'm terribly biased, but R packaging in Guix is --- in my opinion --- very high quality, purely from source (including bundled minified JavaScript), and the tooling is great too.

Unlike R in Nix, Guix does not just automatically wrap R packages, which would lead to build and runtime errors. I would not use R from Nix.

Reply on news.ycombinator.com