Comment by JHonaker | Hacker News Reader

Comment by JHonaker | Hacker News Reader

Parent Full thread

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.)

Reply on news.ycombinator.com