Is this slop?

There’s a lot of skepticism about building your own language using LLMs, and I get it. I was pretty skeptical myself. So let me tell you what actually gives me confidence in T’s correctness: as of writing, 1753 unit tests, 122 golden tests, 13 end-to-end tests, and 18 full project demos are executed on every push and PR, on both Linux and macOS via GitHub Actions. That’s the verification regime, and it has to be rigorous precisely because I can’t audit the OCaml implementation by eye. This is actually one of the more interesting lessons from this project: when you can’t rely on code review, you have to over-invest in tests and specifications. The spec files, the enriched changelog, the summary.md, all of that context makes the LLM’s output more predictable, and the test suite tells you immediately when it isn’t.

From personal experience, when I generate R or Python code, the output looks a lot like what I would have written myself. The main failure mode I’ve noticed is lack of context: the more you give the model, the better the result. Letting separate LLMs review PRs and iterating through several loops helps catch what any single model misses.

I’m also confident in T’s safety from a different angle: it’s ultimately orchestrating Python and R code you write yourself, and that you can test independently.

Interested?

If you’re interested in trying it out or contributing, check out the official repository or the website, and don’t hesitate to open an issue or a PR or contact me on the dedicated Matrix (https://matrix.to/#/#tproject:matrix.org) channel.

Appendix

For the interested reader, here’s how to get started with T.

# 1. Initialize a new project
nix run github:b-rodrigues/tlang -- init --project my_t_project
cd my_t_project

[project]
name = "r_py_xgboost_t"
description = "A T data analysis project"

[dependencies]
# T packages this project depends on
# Format: package = { git = "repository-url", tag = "version" }
# Example:
# stats = { git = "https://github.com/t-lang/stats", tag = "v0.5.0" }

[r-dependencies]
packages = ["dplyr", "yardstick"]

[py-dependencies]
version = "python313"
packages = ["numpy", "pandas", "scikit-learn", "xgboost"]

[additional-tools]
packages = ["quarto"]

[t]
# Minimum T language version required
min_version = "0.51.2"

[latex]
packages = ["amsmath", "geometry", "hyperref", "biblatex"]

nix run github:b-rodrigues/tlang -- init --package my_package
cd my_package

[package]
name = "my_package"
version = "0.1.0"
description = "A brief description of what my_package does"
authors = ["brodriguesco"]
license = "EUPL-1.2"
homepage = ""
repository = ""

[dependencies]
# T packages this package depends on
# Format: package = { git = "repository-url", tag = "version" }

[t]
# Minimum T language version required
min_version = "0.5.0"

nix develop

From implicit to explicit: translating a script into a rixpress pipeline

Let me show you what I mean by translating that old Luxembourg Airport data cleaning code into a {rixpress} pipeline. The original script uses continuous %>% chaining, standard tidyverse style. The {rixpress} version makes every intermediate step explicit.

But here’s the thing: LLMs don’t know about {rixpress} out of the box. It’s a relatively new package, and it’s not in their training data (or if it is, it’s outdated). So I wrote another tool called pkgctx that extracts structured, LLM-ready API specifications from R or Python packages (and guess what, I did not write a single line of code of that tool, LLMs did).

The idea is simple: run pkgctx r rixpress > rixpress.ctx.yaml and you get a compact YAML file describing every function, its arguments, and its purpose. Feed that to an LLM, and suddenly it “knows” the package. All my packages now have such a file generated on each push thanks to GitHub Actions. Here’s how my conversation went:

Me: I want to use a package called rixpress, but I am not familiar with it. You’ll help me, and here is a file with a detailed description of the API, for context.

[uploaded rixpress.ctx.yaml]

LLM: Got it. I’ll use this API specification as the authoritative reference for rixpress and help you write correct, idiomatic pipelines with it.

A few orientation points to set the frame (no action required yet):

• rixpress is declarative: you describe derivations (rxp_r(), rxp_py(), rxp_qmd(), …), then materialize them with rxp_populate() and rxp_make().
• Data flows through the DAG via serialized artifacts (RDS / pickle / Julia Serialization), not in-memory objects.
• Language boundaries are explicit (rxp_r2py(), rxp_py2r()).
• Nix is the execution engine; default.nix (or equivalents) define the runtime environment.

When you’re ready, tell me what you want to do […]

Then I simply asked:

Me: Help me translate this R script into a rixpress pipeline: [pasted the old script]

And that’s how I got a working {rixpress} pipeline. The LLM did the tedious restructuring; I reviewed the output, made minor tweaks, and was done. The combination of pkgctx for context and a clear task (“translate this script”) made the LLM genuinely useful.

Now let’s look at what the translated pipeline looks like. First, let’s assume:

• The data file avia_par_lu.tsv is in the project directory
• Required R packages are available via default.nix (we’ll also use an LLM for this one)
• The project has been initialized with rxp_init() (this sets up two skeleton files to get started quickly)

library(rixpress)

# Step 0: Load the data
avia <- rxp_r_file(
  name = avia,
  path = "avia_par_lu.tsv",
  read_function = readr::read_tsv
)

# Step 1: Select and reshape (wide → long)
avia_long <- rxp_r(
  name = avia_long,
  expr =
    avia %>%
      select("unit,tra_meas,airp_pr\\time", contains("20")) %>%
      gather(date, passengers, -`unit,tra_meas,airp_pr\\time`)
)

# Step 2: Split composite key column
avia_split <- rxp_r(
  name = avia_split,
  expr =
    avia_long %>%
      separate(
        col = `unit,tra_meas,airp_pr\\time`,
        into = c("unit", "tra_meas", "air_pr\\time"),
        sep = ","
      )
)

# Step 3: Recode transport measure
avia_recode_tra_meas <- rxp_r(
  name = avia_recode_tra_meas,
  expr =
    avia_split %>%
      mutate(
        tra_meas = fct_recode(
          tra_meas,
          `Passengers on board` = "PAS_BRD",
          `Passengers on board (arrivals)` = "PAS_BRD_ARR",
          `Passengers on board (departures)` = "PAS_BRD_DEP",
          `Passengers carried` = "PAS_CRD",
          `Passengers carried (arrival)` = "PAS_CRD_ARR",
          `Passengers carried (departures)` = "PAS_CRD_DEP",
          `Passengers seats available` = "ST_PAS",
          `Passengers seats available (arrivals)` = "ST_PAS_ARR",
          `Passengers seats available (departures)` = "ST_PAS_DEP",
          `Commercial passenger air flights` = "CAF_PAS",
          `Commercial passenger air flights (arrivals)` = "CAF_PAS_ARR",
          `Commercial passenger air flights (departures)` = "CAF_PAS_DEP"
        )
      )
)

# Step 4: Recode unit
avia_recode_unit <- rxp_r(
  name = avia_recode_unit,
  expr =
    avia_recode_tra_meas %>%
      mutate(
        unit = fct_recode(
          unit,
          Passenger = "PAS",
          Flight = "FLIGHT",
          `Seats and berths` = "SEAT"
        )
      )
)

# Step 5: Recode destination
avia_recode_destination <- rxp_r(
  name = avia_recode_destination,
  expr =
    avia_recode_unit %>%
      mutate(
        destination = fct_recode(
          `air_pr\\time`,
          `WIEN-SCHWECHAT` = "LU_ELLX_AT_LOWW",
          `BRUSSELS` = "LU_ELLX_BE_EBBR",
          `GENEVA` = "LU_ELLX_CH_LSGG",
          `ZURICH` = "LU_ELLX_CH_LSZH",
          `FRANKFURT/MAIN` = "LU_ELLX_DE_EDDF",
          `HAMBURG` = "LU_ELLX_DE_EDDH",
          `BERLIN-TEMPELHOF` = "LU_ELLX_DE_EDDI",
          `MUENCHEN` = "LU_ELLX_DE_EDDM",
          `SAARBRUECKEN` = "LU_ELLX_DE_EDDR",
          `BERLIN-TEGEL` = "LU_ELLX_DE_EDDT",
          `KOBENHAVN/KASTRUP` = "LU_ELLX_DK_EKCH",
          `HURGHADA / INTL` = "LU_ELLX_EG_HEGN",
          `IRAKLION/NIKOS KAZANTZAKIS` = "LU_ELLX_EL_LGIR",
          `FUERTEVENTURA` = "LU_ELLX_ES_GCFV",
          `GRAN CANARIA` = "LU_ELLX_ES_GCLP",
          `LANZAROTE` = "LU_ELLX_ES_GCRR",
          `TENERIFE SUR/REINA SOFIA` = "LU_ELLX_ES_GCTS",
          `BARCELONA/EL PRAT` = "LU_ELLX_ES_LEBL",
          `ADOLFO SUAREZ MADRID-BARAJAS` = "LU_ELLX_ES_LEMD",
          `MALAGA/COSTA DEL SOL` = "LU_ELLX_ES_LEMG",
          `PALMA DE MALLORCA` = "LU_ELLX_ES_LEPA",
          `SYSTEM - PARIS` = "LU_ELLX_FR_LF90",
          `NICE-COTE D'AZUR` = "LU_ELLX_FR_LFMN",
          `PARIS-CHARLES DE GAULLE` = "LU_ELLX_FR_LFPG",
          `STRASBOURG-ENTZHEIM` = "LU_ELLX_FR_LFST",
          `KEFLAVIK` = "LU_ELLX_IS_BIKF",
          `MILANO/MALPENSA` = "LU_ELLX_IT_LIMC",
          `BERGAMO/ORIO AL SERIO` = "LU_ELLX_IT_LIME",
          `ROMA/FIUMICINO` = "LU_ELLX_IT_LIRF",
          `AGADIR/AL MASSIRA` = "LU_ELLX_MA_GMAD",
          `AMSTERDAM/SCHIPHOL` = "LU_ELLX_NL_EHAM",
          `WARSZAWA/CHOPINA` = "LU_ELLX_PL_EPWA",
          `PORTO` = "LU_ELLX_PT_LPPR",
          `LISBOA` = "LU_ELLX_PT_LPPT",
          `STOCKHOLM/ARLANDA` = "LU_ELLX_SE_ESSA",
          `MONASTIR/HABIB BOURGUIBA` = "LU_ELLX_TN_DTMB",
          `ENFIDHA-HAMMAMET INTERNATIONAL` = "LU_ELLX_TN_DTNH",
          `ENFIDHA ZINE EL ABIDINE BEN ALI` = "LU_ELLX_TN_DTNZ",
          `DJERBA/ZARZIS` = "LU_ELLX_TN_DTTJ",
          `ANTALYA (MIL-CIV)` = "LU_ELLX_TR_LTAI",
          `ISTANBUL/ATATURK` = "LU_ELLX_TR_LTBA",
          `SYSTEM - LONDON` = "LU_ELLX_UK_EG90",
          `MANCHESTER` = "LU_ELLX_UK_EGCC",
          `LONDON GATWICK` = "LU_ELLX_UK_EGKK",
          `LONDON/CITY` = "LU_ELLX_UK_EGLC",
          `LONDON HEATHROW` = "LU_ELLX_UK_EGLL",
          `LONDON STANSTED` = "LU_ELLX_UK_EGSS",
          `NEWARK LIBERTY INTERNATIONAL, NJ.` = "LU_ELLX_US_KEWR",
          `O.R TAMBO INTERNATIONAL` = "LU_ELLX_ZA_FAJS"
        )
      )
)

# Step 6: Final cleaned dataset
avia_clean <- rxp_r(
  name = avia_clean,
  expr =
    avia_recode_destination %>%
      mutate(passengers = as.numeric(passengers)) %>%
      select(unit, tra_meas, destination, date, passengers)
)

# Step 7: Quarterly arrivals
avia_clean_quarterly <- rxp_r(
  name = avia_clean_quarterly,
  expr =
    avia_clean %>%
      filter(
        tra_meas == "Passengers on board (arrivals)",
        !is.na(passengers),
        str_detect(date, "Q")
      ) %>%
      mutate(date = yq(date))
)

# Step 8: Monthly arrivals
avia_clean_monthly <- rxp_r(
  name = avia_clean_monthly,
  expr =
    avia_clean %>%
      filter(
        tra_meas == "Passengers on board (arrivals)",
        !is.na(passengers),
        str_detect(date, "M")
      ) %>%
      mutate(date = ymd(paste0(date, "01"))) %>%
      select(destination, date, passengers)
)

# Populate and build the pipeline
rxp_populate(
  list(
    avia,
    avia_long,
    avia_split,
    avia_recode_tra_meas,
    avia_recode_unit,
    avia_recode_destination,
    avia_clean,
    avia_clean_quarterly,
    avia_clean_monthly
  )
)

rxp_make()

Now this is a faithful “translation” of the script into a {rixpress} pipeline, however, the original data is now not available anymore, and recent data sets have changed slightly, which means that this script would need further adaptation to the current data source. Otherwise, this would be it! You can view the updated script here (I have also removed all the recoding of factors, because there seems to be something wrong with how {rixpress} handles `, so writing this blog post actually help me find something to fix!)

Generating the environment

I also used an LLM to generate the {rix} script that sets up the reproducible environment for this pipeline. I gave it the rix.pkgctx.yaml context file (generated with pkgctx r rix > rix.pkgctx.yaml, which is also available on the rix GitHub repo) and asked: “Using this knowledge, write me an R script that uses rix to set up the right default.nix for this pipeline.”

The LLM correctly identified the packages needed from the pipeline code:

• readr (for read_tsv)
• dplyr (for select, filter, mutate, %>%)
• tidyr (for gather, separate)
• forcats (for fct_recode)
• lubridate (for yq, ymd)
• stringr (for str_detect)
• rixpress (for the pipeline itself)

And produced this script:

library(rix)

rix(
  date = "2026-01-10",
  r_pkgs = c(
    "readr",
    "dplyr",
    "tidyr",
    "forcats",
    "lubridate",
    "stringr",
    "rixpress"
  ),
  ide = "none",
  project_path = ".",
  overwrite = TRUE
)

There’s only one issue with that script: the selected date is not valid, it should instead be the 12th of January. But that’s actually my fault: the LLM had no way of knowing that. The only way it could have known is if I had told it to look at the csv file that lists all the valid dates on {rix}’s repository. But after changing the date, it becomes possible to run this script, then nix-build to build the environment and nix-shell to drop into it. From there, run your pipeline.

What we’ve done here is use LLMs at every step:

1. Gave context about rixpress (via pkgctx) and asked the LLM to translate my old script into a pipeline
2. Gave context about rix (via pkgctx) and asked the LLM to generate the environment setup

The pattern is always the same: context + scoped task = useful output.

Structure + context = outsourceable grunt work

The point I’m making here isn’t really about {rixpress} pipelines specifically. It’s about a broader principle that both Davis Vaughan and I have observed: LLMs are genuinely useful when you give them enough structure and context.

Davis pre-cloned repositories, pre-generated .Rprofile files, and pre-created task lists so Claude could focus on the actual fixes rather than git management. I used pkgctx to give the LLM a complete API specification and provided a clear starting point (my old script). In both cases, the formula is the same:

Structure + Context → Scoped Task → LLM can actually help

I’ve written before about how you can outsource grunt work to an LLM, but not expertise. The same applies here. I still had to know what data transformations I needed. I still had to review the output and make adjustments. But the tedious restructuring (turning a monolithic script into a declarative pipeline) is exactly the kind of work LLMs can handle if you set them up properly.

If you want LLMs to help with your data science work:

1. Give them context. Use tools like pkgctx to feed them API specifications. Paste your existing code. Show them examples.
2. Scope the task tightly. “Translate this script into a rixpress pipeline” is a well-defined task. “Make my code better” is not.
3. Review the output. LLMs do grunt work; you provide expertise.

If you’re not familiar with {rixpress}, check out my announcement post or the CRAN release post. And if you want to give LLMs context about R or Python packages, pkgctx is there to help. For those who want to dive deeper into Nix, {rix}, and {rixpress}, I’ve recently submitted a paper to the Journal of Statistical Software, which you can read here. For more examples of {rixpress} pipelines, check out the rixpress_demos repository.

LLMs aren’t going anywhere: the genie is out of the bottle. I still see plenty of people online claiming that LLMs aren’t useful, but I genuinely believe it comes down to one of two things:

• They’re not providing enough context or scoping their tasks well enough.
• They have a principled objection to LLMs, AI, and automation in general which, ok, whatever, but it’s not a technical argument about usefulness.

Some people might even say that to feel good about themselves: what I program is much too complex and important for mere LLMs to be able to help me. Ok perhaps, but not all of us are working for NASA or whatever. I’ll keep on outsourcing the tedious grunt work to LLMs.

An optimised layout for a polyglot country

5 years ago I discussed what features a keyboard optimised for Luxembourg should have. I’m talking about Luxembourg the country, and not Luxembourgish the language, because in Luxembourg no one types only Luxembourgish. The most commonly typed language is probably French, and English a close second. German follows in third and then Luxembourgish (some people might argue that, in their own experience, German is more widely typed than French, but I seriously doubt it). Whatever the actual ranking, an optimised keyboard for Luxembourg should be a keyboard in which typing these 4 languages is comfortable. That blog post from 5 years ago dug into that (letter frequency and so on), but until today, I left it on the back burner.

Now, with LLMs it was trivial to continue working on this, implement an effort model, and use an optimisation algorithm to minimise said effort. Today, I can present the layout I’ve obtained:

(there is an error in the layout shown here, there are two “G”s; the one on the right of E should not be there, and instead should be a “,”. This is a bug in the function that creates the heatmap, not in the layout itself.)

⚠️ This is a work in progress! The layout, the name, and even the methodology are all open for discussion. I’m sharing this early because I’d love to hear from the community, especially those who type in multiple languages daily. Your feedback will shape the final version.

Let me also clarify what my goal with this is: do I want to actually suggest a layout that shall be adopted nationally and become a standard? Well, maybe. But I definitely won’t do it alone. So if you’re interested, we could work together and write a layout that could actually be used by different operating systems and pitch it to decision makers.

France Shows the Way

In 2019, France officially adopted two new keyboard standards:

1. A revised AZERTY that fixes many issues while maintaining familiarity
2. BÉPO — a completely redesigned layout optimised for French

I’ve been using BÉPO for years, and I can honestly say it’s a game-changer. Typing feels more natural, there’s less finger movement, and the learning curve, while steep at first, pays off significantly.

But here’s the thing: BÉPO was designed primarily for French. Luxembourg is unique, because we need something that works for French and German and Luxembourgish and English.

The QWERTZ-LUX Approach

So I started wondering: what would an optimised keyboard layout for Luxembourg look like? You can read about my findings here, but basically, any optimised layout for any of these 4 languages would actually work rather well; this is because 3 out of these 4 languages are Germanic languages, but also, the top 10 most used characters for these 4 languages are essentially the same.

So I had three options:

1. Simply propose that we also adopt BÉPO
2. Create a fully optimised layout using these 4 languages for setting up the optimisation problem
3. Keep QWERTZ as a base for familiarity and only move around a minimal set of characters to improve comfort.

I chose a middle path, inspired by Carpalx’s partial optimization philosophy. Martin Krzywinski demonstrated that you don’t need to remap the entire keyboard to reap most of the rewards. Just 5 strategic key swaps can achieve 70% of the effort reduction of a fully optimised layout, while the learning curve remains manageable.

QWERTZ-LUX (final name pending) follows this principle. It’s essentially a fork of BÉPO’s structure, but with modifications that:

• Keep familiar elements for QWERTZ users (Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V shortcuts)
• Optimize the letter arrangement for our multilingual corpus
• Provide direct access to accented characters (é, à, ü, ö, ç, ä) without dead keys

The home row had to change substantially, because QWERTZ’s home row is simply too inefficient. But I tried to minimize disruption elsewhere, following the partial optimization insight that the first few key swaps matter most. Setting up the optimisation problem with these constraints resulted in a keyboard layout that stays familiar, while being much more efficient.

The Corpus: What Does Luxembourg Type?

To evaluate keyboard layouts fairly, we need text that reflects what people actually type in Luxembourg. I created a balanced multilingual corpus with:

• 30% French — Administrative and business language
• 30% English — International communication
• 20% German — Media and education
• 20% Luxembourgish — Daily life and national identity

Again, your mileage may vary. When I first started working in Luxembourg, I only used English and French. Now I also use Luxembourgish more often, and I know people who only write French. Either way, a national keyboard layout should be able to be comfortable for any of these languages.

What actually matters is the top letters across all languages, which are E, N, S, T, R, I, A, the letters you’d want on your home row.

The Effort Model Explained

Before comparing layouts, let’s understand how we measure “typing effort”. I wrote an R package called lbkeyboard that implements a model inspired by Carpalx, the seminal keyboard layout optimization tool created by Martin Krzywinski.

Total = Σ (base × frequency) + Σ (same_finger_penalty) + Σ (same_hand_penalty)
        + Σ (row_change_penalty) + Σ (layer_penalties)

# Load layouts
data("ch_qwertz")
data("afnor_bepo")
qwertz_lux <- create_qwertz_lux_keyboard()

# Effort weights (same as used throughout)
effort_weights <- list(
  base = 3.0,
  same_finger = 3.0,
  same_hand = 0.5,
  row_change = 0.5,
  trigram = 0.3
)

pangram <- "the quick brown fox jumps over the lazy dog"

# Calculate effort for each layout
pangram_qwertz <- calculate_layout_effort(ch_qwertz, pangram, 
                                          keys_to_evaluate = letters,
                                          effort_weights = effort_weights)
pangram_bepo <- calculate_layout_effort(afnor_bepo, pangram,
                                        keys_to_evaluate = letters,
                                        effort_weights = effort_weights)
pangram_lux <- calculate_layout_effort(qwertz_lux$base, pangram,
                                       keys_to_evaluate = letters,
                                       effort_weights = effort_weights)

data.frame(
  Layout = c("QWERTZ", "BÉPO", "QWERTZ-LUX"),
  Effort = round(c(pangram_qwertz, pangram_bepo, pangram_lux), 2),
  `vs QWERTZ` = paste0(round((1 - c(pangram_qwertz, pangram_bepo, pangram_lux) / 
                               pangram_qwertz) * 100, 1), "%"),
  check.names = FALSE
)
#>       Layout Effort vs QWERTZ
#> 1     QWERTZ 338.69        0%
#> 2       BÉPO 268.79     20.6%
#> 3 QWERTZ-LUX 303.08     10.5%

How Much Better Is It?

Using this effort model (with the weights shown above), here’s how the layouts compare:

Visualizing the Difference: Heatmaps

Heatmaps show where your fingers spend time. Brighter colors = more keystrokes. Ideally, you want the brightness concentrated on the home row.

Notice how BÉPO and QWERTZ-LUX concentrate activity on the home row, while QWERTZ spreads effort across all rows.

What’s Next?

So I’d like to know what others think. Is this something you’d be interested in exploring further? The next step would be to write a layout.ini file for Portable Keyboard Layout for Windows, and write layout files for Linux and macOS, and have real people test it in real-world settings. We could see if it feels comfortable and what else could be optimised.

But is there a chance that such a layout will ever get adopted? After all, there are obstacles:

• People just don’t care and won’t ever switch
• Even if people cared, Luxembourg is too small a market and keyboards will never ship with a Luxembourg-specific layout

In my opinion, rolling out such a keyboard would require a phased and gradual approach:

• Have kids learn to touch type in school on the optimised layout
• Distribute keyboard layout stickers, which are cheap

After some years, the switch would be complete, so I think it’s feasible, but only if there is a community around this layout. Also, who knows, this layout could technically be adopted in Switzerland and other German-speaking nations (maybe as a variant without direct access to French accented letters).

About the Name

The current working name “QWERTZ-LUX” is descriptive but not final. The first letters of the layout are QWFOG, which doesn’t exactly roll off the tongue like “QWERTY” or “BÉPO.” Here are some alternatives I’m considering:

What do you think? I’m genuinely open to suggestions: a good name helps adoption!

Oh, and happy new year I guess.

Juggling imperative tools

Without Nix, you have to use language-specific package managers and tooling to first set up the environment. So for Python I’ve used uv (which is fantastic to be honest), then to install the right version of R I’ve used rig and a Posit CRAN snapshot for packages and for Julia I’ve simply downloaded a pre-compiled package of the version I needed, and used its built-in package manager to install specific versions of packages as well.

Also, to deal with system level dependencies, I’ve bundled everything inside a Docker image. This is a sketch of the Dockerfile:

# Add R repository and install specific version
RUN apt-get update && apt-get install -y software-properties-common
RUN add-apt-repository ppa:...
RUN curl -L https://rig.r-pkg.org/... | sh
RUN rig add 4.5.1

# Install Python with uv
RUN curl -LsSf https://astral.sh/uv/install.sh | sh
RUN uv python install 3.13

# Download and extract Julia
RUN curl -fsSL https://julialang-s3.julialang.org/... -o julia.tar.gz
RUN tar -xzf julia.tar.gz -C /opt/

# Install packages for each language separately
RUN echo 'options(repos = c(CRAN = ...))' > /root/.Rprofile
RUN Rscript -e 'install.packages(...)'

# Install Python packages using uv with specific versions for reproducibility.
RUN echo "pandas==2.3.3" > /tmp/requirements.txt && \
    echo "scikit-learn==1.7.2" >> /tmp/requirements.txt && \
    # ... more packages ...

RUN uv pip install --no-cache -r /tmp/requirements.txt && \
    rm /tmp/requirements.txt

# Install specific versions of Julia packages for reproducibility
RUN julia -e 'using Pkg; \
    Pkg.add(name="Arrow", version="2.8.0"); \

This traditional approach feels like you’re a sysadmin first and a data scientist second. The Dockerfile is a long, step-by-step, imperative script of shell commands. You have to write how stuff needs to be installed, and this of course varies for each language. Each language needs its own special treatment, its own package installation command, and its own set of dependencies. For example, for Python, I actually even needed more configuration than what I’ve shown above:

# Ensure the installed binary is on the `PATH`
ENV PATH="/root/.local/bin/:$PATH"

# Install the specified Python version using uv.
RUN uv python install ${PYTHON_VERSION}

# Setup default virtual env
RUN uv venv /opt/venv
# Use the virtual environment automatically
ENV VIRTUAL_ENV=/opt/venv
# Place entry points in the environment at the front of the path
ENV PATH="/opt/venv/bin:$PATH"

This is because I needed to set the virtual environment installed by uv as the one to be used by default. This is ok inside Docker, but that’s not something you’d likely want to do on a real machine. The final Dockerfile for our “simple” example was over 100 lines long (including comments).

Now that the environment is said, we actually need to orchestrate the workflow. I’ve used Make for this, which means writing a Makefile. Honestly, nowadays, thanks to LLMs that’s not so much of an issue. But before LLMs, it would be quite annoying, because you need to manually define which file depends on which other file. Here’s what it looks like:

# ==============================================================================
# Makefile for the Polyglot RBC Model Pipeline
# ==============================================================================

# Define the interpreters for each language.
JULIA := julia
PYTHON := python
RSCRIPT := Rscript
QUARTO := quarto

# Define directory variables for better organization.
DATA_DIR := data
PLOTS_DIR := plots
REPORT_DIR := report
FUNCTIONS_DIR := functions

# Define the final and intermediate data files.
SIMULATED_DATA := $(DATA_DIR)/simulated_rbc_data.arrow
PREDICTIONS := $(DATA_DIR)/predictions.arrow
FINAL_PLOT := $(PLOTS_DIR)/output_plot.png
FINAL_REPORT := $(REPORT_DIR)/readme.html

# --- Main Rules ---

# The default 'all' rule now points to the final compiled HTML report.
all: $(FINAL_REPORT)

# Rule to render the final Quarto report.
# Depends on the Quarto source file and the plot from the R step.
$(FINAL_REPORT): readme.qmd $(FINAL_PLOT) | $(REPORT_DIR)
    @echo "--- [Quarto] Compiling final report ---"
    $(QUARTO) render $< --to html --output-dir $(REPORT_DIR)

... and so on ...

That’s another 65 lines for the orchestration.

Finally, and probably worst of all, is that you end up writing tons of “glue code.” Because make just runs scripts, every step of your analysis (the Julia simulation, the Python training) needs to be wrapped in a script that does nothing but parse command-line arguments, read an input file, call your actual analysis function, and write an output file. That’s a lot of code just to get things talking to each other.

The final tally for the traditional, imperative, approach? Nine separate files just to manage the environment and run the pipeline. It’s a fragile, complicated house of cards, but it takes only 3 minutes to run on a standard Ubuntu GitHub Actions runner.

Nix: Declarative, Simple, and Clean

Nix makes this whole process so much easier, it’s actually not even fair. Instead of telling the computer how to do everything, you just declare what you want. You describe your requirements, and Nix figures the rest out. But because Nix is not that easy to get into, I wrotk the {rix} and {rixpress} packages as high-level interfaces to Nix’s power.

For example, to set up the environment, you just list the R, Python, and Julia packages you need, and {rix} handles everything else. It figures out how to install them, resolves all the system-level dependencies, and generates the complex Nix expression for you. You don’t need to be a sysadmin; you just need to know what packages your analysis requires. This is because all the sysadminy work was handled upstream by Nix package maintainers (real MVPs); Nix maintainers encode the build recipes, dependency graphs, and patches needed for each package, so you don’t have to. (Reminds me of this quote from Jenny Bryan: Of course, someone has to write for loops. It doesn’t have to be you, but here it’s unglamorous Nix code to make packages work well instead of loops.)

Here’s what the gen-env.R script looks like:

rix(
  date = "2025-10-14",
  r_pkgs = c("ggplot2", "dplyr", "arrow"),
  jl_conf = list(jl_version = "lts", ...),
  py_conf = list(py_version = "3.13", ...),
  ...
)

Then, for the pipeline, it’s the same story. You just write what you need, not how it’s done. Nix can handle this. Here’s what the gen-pipeline.R script looks like:

# gen-pipeline.R - a small part
list(
  rxp_jl(name = simulated_rbc_data, expr = "simulate_rbc_model(...)"),
  rxp_py(name = predictions, expr = "train_model(simulated_rbc_data)"),
  rxp_r(name = output_plot, expr = "plot_predictions(predictions)"),
  ...
)

Dependencies are inferred automatically. {rixpress} sees that predictions uses the simulated_rbc_data object and knows to run the Julia step first. It handles all the I/O for you as well. Objects get serialised and unserialised transparently for you.

Your scientific code now lives in pure functions, free of any command-line parsing or file I/O. You can focus entirely on the analysis.

The final tally for the Nix-based approach? Six files, and four of them (gen-env.R, gen-pipeline.R, and the two functions files) are simple, clean declarations of what you need and what you want to do. The whole set up of the environment and execution of the pipeline takes 5 minutes on a standard GitHub Actions runner. That’s 2 minutes longer that the imperative approach, but I think it’s a small price to pay. Plus, you’re not setting up the environment from scratch each time you execute the pipeline, so subsequent executions will only take seconds.

The biggest difference isn’t just the simplicity; it’s the guarantee. The Docker approach gives you reproducibility today. But a year from now, if you rebuild the Dockerfile, mutable base images and shifting package dependencies mean you might get a subtly different environment. The underlying base Docker image will change, and in some years, will completely stop functioning (Ubuntu 24.04, which is quite often used as the base image, will reach of end of life in 2029).

The Nix approach, by pinning everything to a specific date, gives you temporal reproducibility. Your environment will build the exact same way today, next year, or five years from now, for as long as the nixpkgs GitHub repository will stay online (we can hope for a 1000 years if Microsoft doesn’t fuck it up). It’s a level of long-term stability that the traditional stack simply can’t match without a heroic amount of manual effort. But also, it’s just so much simpler!

CRAN doesn’t tolerate this nonsense

In R, this situation simply doesn’t happen. Why? Because CRAN enforces a system where packages are tested not only in isolation, but against their reverse dependencies. If {ggplot2} or {dplyr} changes in a way that breaks others, CRAN catches it. Package authors get a warning, and if they don’t fix things (within 2 weeks!), their package gets archived, which means that when users try to install it with install.packages("foo"), it won’t work. Which means that if a package is on CRAN, install.packages("foo") will work. Not “works if you’re lucky.” Not “works if you pin the right versions.” It just works (of course, as long as the right system-level dependencies are available if you need to compile it, which isn’t an issue if you’re installing binaries though). Actually, you can’t even publish a package that has constraints on the version of its dependencies. Your package has to work with all packages on CRAN forever and ever. Honestly, quite impressive for something that’s not even a real programming language, right? (this is sarcastic btw)

And CRAN manages this consistency across 27000 packages. PyPI is much bigger, granted, but I doubt that many more than 30k packages get actually used frequently. In fact, probably a couple thousand, maybe even a couple hundred do (especially for data analysis).

PyPI is a warehouse, not an ecosystem

PyPI doesn’t do this. It’s a dumping ground for tarballs and wheels. No global checks, no compatibility guarantees, no consistency across the ecosystem. If package A and package B declare mutually exclusive requirements, PyPI shrugs and hosts them both.

We then spend enormous effort building tools to try to deal with this mess: Conda, Poetry, Hatch, uv, pipx and Nix (well Nix was not specifically made for Python, but it can also be used to set up virtual environments). They’re all great tools, but they can’t solve the core problem: if the constraints themselves are impossible, no resolver can save you. At best, these tools give you a way to freeze a working mess before it collapses. Just pray to whichever deity you fancy that adding a new package down the line doesn’t explode your environment.

This is not an ecosystem. It’s chaos with good packaging tools.

But Nix does help a bit more; at least with Nix, you can patch a package’s pyproject.toml to try to relax imcompatible dependencies, like I did for saiph:

postPatch = ''
  # Remove these constraints
  substituteInPlace pyproject.toml \
    --replace 'numpy = "^1"' 'numpy = ">=1"' \
    --replace 'msgspec = "^0.18.5"' 'msgspec = ">=0.18.5"'
'';

This step relaxed the constraints directly in the pyproject.toml, but that might not be a good idea: these constraints might have been there for a good reason. Unit tests did pass though (more than 150 of them) so in this particular case I think I’m good. If PyPI was managed like CRAN, saiph’s authors would have had 2 weeks to make sure that saiph worked well with Numpy 2, which seems to be the case here. But patching packages is certainly not a solution for everything.

The scale myth

“But Python is too big and diverse for CRAN-style governance!” I hear you yell. This is simply false. CRAN manages 27000 packages across domains as varied as bioinformatics, finance, web scraping, geospatial analysis, and machine learning, and this is without counting old packages that have been archived through the years. The R ecosystem isn’t small or homogeneous. It is smaller than PyPI in absolute numbers, yes, but honestly, I doubt there are more data analytics packages on PyPI than on CRAN, and if older unmaintained Python packages would get removed, the number of PyPI packages would also be much smaller. If anyone has hard statistics on it, I’d be happy to read them.

The difference isn’t technical capacity or ecosystem size. It’s governance philosophy. CRAN chose consistency over permissiveness. PyPI chose the opposite.

And no, conda-forge isn’t enough

Conda-forge is curated in that its builds are consistent, compilers are pinned, migrations are coordinated. That’s great, and it proves Python packaging can work at scale.

But if package A wants numpy < 2 and package B wants numpy >= 2, conda-forge will host them both, and you’re still stuck. There’s no enforcement mechanism that forces the ecosystem to resolve contradictions. CRAN has that. Conda-forge doesn’t.

Conda-forge is a step in the right direction, but a tighter governance is needed.

What Python actually needs: PyPAN

Python needs a curated layer on top of PyPI that enforces consistency. Call it PyPAN: the Python Package Archive Network.

Here’s what PyPAN would do:

• Mirror packages from PyPI, but only those that pass ecosystem-wide checks
• Test every package against its reverse dependencies, not just itself
• Coordinate migrations for major breaking changes (e.g. numpy 2.0)
• Archive packages that refuse to adapt
• Publish consistent, installable snapshots of the entire ecosystem

In other words: CRAN, but for Python.

If CRAN can maintain consistency across 27’000 packages (by such a small team by the way), Python can too. The question isn’t whether it’s technically possible but whether the Python community is willing to prioritize ecosystem stability over individual package autonomy.

Why developers would submit to PyPAN

Why would a package author bother? Simple:

• Visibility: users will prefer packages on PyPAN because they actually install and work
• Less support burden: fewer bug reports about broken installs or dependency hell
• Shared responsibility: migration effort spread across the ecosystem, not left to individual maintainers
• Credibility: “on PyPAN” becomes a mark of quality and stability — especially for scientific and industry projects

If you don’t opt in, fine. But eventually, users will prefer packages that are part of the curated, consistent set. Just like people prefer CRAN packages in R and avoid installing from GitHub if possible.

Maybe let’s start small

CRAN’s model proves that ecosystem-wide consistency is achievable, and I’m of the opinion that it could be also achievable at at Python’s scale. Conda-forge proves that curated Python packaging works.

Until Python has something like PyPAN, nothing changes. Dependency hell will keep developers up at night.

But we could start small. PyPAN could begin by focusing on data science, analysis, and statistics packages - the core scientific Python ecosystem. This subset is:

• More manageable: ~500-1000 packages (I made up this range, could be more could be less, point is, it’s not the 300000 PyPi packages) instead of the entire PyPI
• Highly interconnected: numpy, pandas, scikit-learn, matplotlib, scipy form a natural dependency graph
• Stability-focused: data scientists prioritize reproducible results over bleeding-edge features
• Community-minded: scientific Python already coordinates major migrations (Python 2→3, NumPy 2.0)
• Proven demand: these users already gravitate toward conda-forge for stability

A PyPAN-DS (Data Science) could demonstrate the model works, build trust, and create momentum for broader adoption. Once people see that pip install pandas (or uv if you prefer) can work as reliably as install.packages('dplyr'), expanding to web frameworks and other domains becomes much easier to sell.

The scientific Python community has the cohesion, the need, and the precedent for this kind of coordination. They could be Python’s CRAN pilot program.

Soooo… who’s building this?

Current Capabilities of {rixpress}

Here are the features currently available in {rixpress}:

• A key motivation was to simplify building pipelines where different steps might require different language environments. With {rixpress}, this is a central feature:

• Define steps in R (rxp_r(), rxp_r_file()) or Python (rxp_py(), rxp_py_file()).

• Importantly, each step can be configured to run in its own Nix-defined environment (for example, use nix_env = "my-python-env.nix" for a Python step, or nix_env = "my-r-env.nix" for an R step). These environments can be generated using my other package, {rix}.

• Pass data between R and Python steps. {rixpress} manages the serialization, using reticulate by default for R/Python object conversion, and also allows custom functions for other formats like JSON or model-specific files.

• Build Quarto (or R Markdown) documents using rxp_quarto() (and rxp_rmd()). These documents can access any artifact (rxp_read("my_artifact")) from preceding steps, regardless of the language used to generate it. Quarto rendering can also occur within its own dedicated Nix environment.

• Every step in a {rixpress} pipeline is treated as a Nix derivation. This means hermetic builds, sandboxed execution, and content-addressable caching, leading to a high degree of reproducibility (as expected with Nix).

• As pipelines grow, visualization is helpful. rxp_ggdag() (using {ggdag}) and rxp_visnetwork() (using {visNetwork}) provide a visual overview of dependencies. dag_for_ci() exports the DAG as an {igraph} dot file format, which can then be used for text-based visualisation on CI.

• For CI, rxp_ga() can generate a GitHub Actions workflow to run the pipeline on each push. This workflow includes caching of Nix store paths between runs (using export_nix_archive() and import_nix_archive()) to avoid unnecessary rebuilds.

• There is ample documentation, and even a vignette detailling how to use {cmdstanr} within a {rixpress} pipeline. {cmdstanr} works in a specific way, by compiling Stan models to C++, and so this requires careful management of Stan model compilation and sampling within the Nix sandbox, demonstrating that complex tools can be integrated.

• It is possible to retrieve outputs from previous pipeline executions. {rixpress} maintains timestamped build logs. Functions like rxp_list_logs(), rxp_inspect(which_log = "..."), and rxp_read("derivation_name", which_log = "...") allow you to access the history of your pipeline’s execution and retrieve specific artifacts.

An Invitation for Feedback

Considerable effort has gone into making {rixpress} robust and useful. A collection of examples is available at the rixpress_demos GitHub repository to illustrate various use cases (R-only, Python-only, R/Python, Quarto, {cmdstanr}, and an XGBoost example).

I’m now looking for feedback from users: * I encourage you to try it out. I recommend watching this tutorial video to get started quickly. * Install it, explore the examples, and perhaps apply it to one of your projects. * Any observations on what works well, what might be confusing, or any issues encountered would be helpful. * Your feedback would be very valuable. Please feel free to open an issue on the {rixpress} GitHub repository with bug reports, feature suggestions, or questions.

Why use {rixpress} instead of {targets}?

{targets} is a fantastic package, and the main source of inspiration of {rixpress}. If you have no need for multilanguage pipelines, then running {targets} inside of a Nix environment, as described here is perfectly valid. But I think that {rixpress} has its place if:

• you need to use multiple languages, as you don’t need adapt Python code to work with {reticulate},
• you’re already convinced by Nix and use {rix},
• want to use a simple pipeline-tool, with a smaller scope.

rixpress, a package to define reproducible analytical pipelines

The Nix programming language is a domain specific language used to package and build software, and “software” can have a very broad definition. As I explored in this blog post, Nix (the programming language) can be used to define a polyglot pipeline to build, for example, a Quarto report using R and Python. I have now built a package called {rixpress} which is heavily inspired by {targets} (if you are not familiar with {targets}, I introduce it at the end of this blog post) to generate such pipelines and build them using Nix. Below is a complete example which starts by using Python and the Polars library to load a dataset, then transforms it a bit, and converts the data to a Pandas dataframe then passes it to R (conversion is done via reticulate::py_load_object() under the hood, also why I had to convert the Polars dataframe to a Pandas dataframe) and finally compiles a Quarto document (you can find the code here):

library(rixpress)

d0 <- rxp_py_file(
  name = mtcars_pl,
  path = 'data/mtcars.csv',
  read_function = "lambda x: polars.read_csv(x, separator='|')",
  nix_env = "py-env.nix"
)

d1 <- rxp_py(
  # reticulate doesn't support polars DFs yet, so need to convert
  # first to pandas DF
  name = mtcars_pl_am,
  py_expr = "mtcars_pl.filter(polars.col('am') == 1).to_pandas()",
  nix_env = "py-env.nix"
)

d2 <- rxp_py2r(
  name = mtcars_am,
  expr = mtcars_pl_am
)

d3 <- rxp_r(
  name = mtcars_head,
  expr = my_head(mtcars_am),
  additional_files = "functions.R"
)

d4 <- rxp_r(
  name = mtcars_tail,
  expr = tail(mtcars_head)
)

d5 <- rxp_r(
  name = mtcars_mpg,
  expr = dplyr::select(mtcars_tail, mpg)
)

doc <- rxp_quarto(
  name = page,
  qmd_file = "page.qmd",
  additional_files = c("content.qmd", "images"),
  nix_env = "quarto-env.nix"
)

rxp_list <- list(d0, d1, d2, d3, d4, d5, doc)

rixpress(rxp_list, project_path = ".")

plot_dag()

Let’s go through this code:

d0 <- rxp_py_file(
  name = mtcars_pl,
  path = 'data/mtcars.csv',
  read_function = "lambda x: polars.read_csv(x, separator='|')",
  nix_env = "py-env.nix"
)

rxp_py_file() uses Python to load a local file. In this case, it’s the mtcars.csv dataset under the data/ folder. The read function must be a function of only one parameter, the path to the data, so I use an anonymous function wrapping polars.read_csv which allows me to set the separator to the unix pipe |. Also, this code is executed inside the environment defined by the py-env.nix file. This file can be generated by my other package, {rix} and lists the Python packages needed (you’ll find it in the repo).

Then:

d1 <- rxp_py(
  # reticulate doesn't support polars DFs yet, so need to convert
  # first to pandas DF
  name = mtcars_pl_am,
  py_expr = "mtcars_pl.filter(polars.col('am') == 1).to_pandas()",
  nix_env = "py-env.nix"
)

rxp_py() executes Python code, and saves the output into the name argument. In this case, I filter the Polars dataframe and convert it to a Pandas dataframe. This again happens inside the environment defined by py-env.nix, it’s a pure Python env, no {reticulate} needed at this stage.

Then:

d2 <- rxp_py2r(
  name = mtcars_am,
  expr = mtcars_pl_am
)

rxp_py2r() calls reticulate::py_load_object() to convert the Pandas dataframe to an R dataframe. We can now continue using it using R! You’ll notice that no nix_env argument is passed to this function. When no argument is provided to nix_env, the default environment, default.nix gets used. This one must always be present and in this case contains the required R packages for the pipeline.

Then:

d3 <- rxp_r(
  name = mtcars_head,
  expr = my_head(mtcars_am),
  additional_files = "functions.R"
)

This one uses an argument we don’t know yet, additional_files. It allows you to pass R scripts that define functions. In this case, functions.R contains the definition of my_head() which is used on mtcars_am.

d4 and d5 are self-explanatory, so now let’s take a look at rxp_quarto():

doc <- rxp_quarto(
  name = page,
  qmd_file = "page.qmd",
  additional_files = c("content.qmd", "images"),
  nix_env = "quarto-env.nix"
)

This compiles the page.qmd document, which requires additional files: content.qmd which gets included into page.qmd and the images/ folder, that contains images required to compile the document. This file is compiled using the quarto-env.nix environment.

Putting all these derivations into a list and passing it to rixpress() doesn’t build the pipeline just yet, but generates a pipeline.nix file which is the Nix expression that will build the output, in this case our Quarto document. You can also take a look at the DAG using plot_dag():

and it’s also possible to retrieve objects in an interactive sessions using rxp_read() (to read them) or rxp_load() (to load them in the global environment). When reading or loading Python objects, this will get converted using {reticulate} on the fly.

To build the pipeline, run rxp_make(). Subsequent runs don’t build everything, as intermediary outputs are cached in the Nix store. So if you change only the Quarto document, only this one derivation gets built anew. It is also possible to export and import the outputs using export_nix_archive() and import_nix_archive(), pretty useful for CI!

Caveats

This package is still in the prototype stage, so don’t use it for anything serious. There are still some things I need to work on, for now debugging a faulty pipeline is really hard because intermediary outputs are difficult to find if the pipeline wasn’t completely built.

Also, due to how Nix works, every computation happens in a completely isolated sandbox. This is why the rxp_*() functions have that additional_files argument, because in case something external is required, Nix needs to copy it over into the sandbox. This means also that functions that require Internet access to work will fail. But I was able to work around that for rxp_file(): so if a resource is online, the function that reads it should be able to get to it.

Now, let me introduce {targets}, my main source of inspiration for this package

The targets package, my source of inspiration for rixpress

I’m a huge fan of the {targets} package and think that it’s truly one of the best packages ever made. No other build/pipeline automation tool comes close in my opinion. Most of these tools require you to define your pipeline in another language (such as yaml) or force you to use some very specific syntax where you explicitely need to define the objects to compute, their inputs and outputs. But {targets} allows you to define your pipeline as a series of R calls:

# _targets.R file
library(targets)
library(tarchetypes)
tar_source()
tar_option_set(packages = c("readr", "dplyr", "ggplot2"))
list(
  tar_target(file, "data.csv", format = "file"),
  tar_target(data, get_data(file)),
  tar_target(model, fit_model(data)),
  tar_target(plot, plot_model(model, data))
)

This may look foreign to many R users, but if you look closely, you’ll realise that most of this code is boilerplate:

# _targets.R file
library(targets)
library(tarchetypes)
tar_source()
tar_option_set(packages = c("readr", "dplyr", "ggplot2"))
list(
  tar_target(....),
  tar_target(....),
  tar_target(....),
  tar_target(....)
)

and what matters is defined inside the tar_target() functions. Remove the boilerplate, and you end up with essentially correct R code, after a few adjustments:

file <- "data.csv"
data <- get_data(file)
model <- fit_model(data)
plot <- plot_model(model, data)

but why go through the trouble of using {targets}? Well, the biggest reason is that {targets} figures out the dependencies between the objects you want to compute, and caches them. So in the example above, if you only change the code of the fit_model() function, only model and plot are re-computed. But if you change file and point the path to an updated data.csv file, then everything gets computed anew. Watch the intro video from the official walkthrough for a visual explanation: but trust me, {targets} is in this class of tools that make you wonder how you could possibly have gotten anything done before using it.

Conclusion

I think that {rixpress} can become quite an useful package, so I will likely submit it for rOpenSci peer review in due time.

And thanks to Grant McDermott for suggesting the name “rixpress”!

Here’s why

nixpkgs is a GitHub repository that contains tens of thousands of Nix expressions used by the Nix package manager to install software. By default, the nix package manager will pull expressions from NixOS/nixpkgs, but when using {rix} our fork rstats-on-nix/nixpkgs is used instead.

Because forks can sometimes be a bit controversial, we decided a blog post was in order.

First of all, let’s make something clear: this doesn’t mean that we don’t contribute to upstream anymore, quite the contrary. But Nix is first and foremost the package manager of a Linux distribution, NixOS, and as such, the way it does certain things only make sense in that context. For our needs, having a fork gives us more flexibility. Let me explain.

As you’ll know, if you’ve been using {rix} and thus Nix, it is possible to use a commit of the nixpkgs GitHub repository as the source for your packages. For example, the 6a9bda32519e710a0c0ab8ecfabe9307ab90ef0c commit of nixpkgs will provide {dplyr} version 1.1.4 while this commit 407f8825b321617a38b86a4d9be11fd76d513da2 will provide version 1.0.7.

While it is technically possible for Nix to provide many versions of the same package (for example, you can install the latest Emacs by installing the emacs package, or Emacs 28 by installing emacs28) this ultimately depends on whether the maintainer wishes to do so, or whether it is practical. As you can imagine, with more than 20’000 CRAN and Bioconductor packages, that is not possible for us (by “us”, I mean the maintainers of the R ecosystem for Nix). So for a given nixpkgs commit, you won’t be able to easily install a specific version of {dplyr} that is not included in that particular nixpkgs commit. Instead, you can install it from source, and this is possible with {rix} by writing something like:

rix(..., r_pkgs = "dplyr@1.0.7", ...)

but because this attempts to install the package from source, it can fail if that package needs Nix-specific fixes to work.

Also, it isn’t practical to update the whole of the R packages set on Nix every day: so while CRAN and Bioconductor get updates daily, the R packages set on Nix gets updated only around new releases of R. Again, this is a consequence of Nix being first and foremost the package manager of a Linux distribution with its own governance and way of doing things.

This is where the rstats-on-nix fork of nixpkgs is interesting: because it is a fork, we can afford to do things in a way that could not be possible or practical for upstream.

The first thing this fork allows us to do is offer a daily snapshot of CRAN. Every day, thanks to Github Actions, the R packages set gets updated, and the result commited to a dated branch. This has been going on since the 14th of December 2024 (see here). So when you set a date as in rix(date = "2024-12-14", ...) this the fork that is going to get used. But this doesn’t mean that we recommend you use any date from the rstats-on-nix/nixpkgs fork: instead, each Monday, another action uses this fork and tries to build a set of popular packages on Linux and macOS, and only if this succeeds is the date added through a PR to the list of available dates on {rix}!

The reason this is done like this is to manage another risk of the upstream nixpkgs. As you know, nixpkgs is huge, and though the utmost care is taken by contributors and the PR review process is very strict, it can happen that updating packages breaks other packages. For example recently RStudio was in a broken state due to an issue in one its dependencies, boost. This is not the fault of anyone in particular: it’s just that packages get updated and packages that depend on them should get updated as well: but if that doesn’t happen quickly enough, the nixpkgs maintainer faces a conundrum. Either he or she doesn’t update the package because it breaks others, but not updating a package could be a security vulnerability, or he or she updates the package, but now others, perhaps less critical packages are broken and need to be fixed, either by their upstream developers, or by the nixpkgs maintainer of said packages. In the case of RStudio a fix was proposed and promptly merged, but if you wanted to install RStudio during the time it took to fix it, you would have faced an error message, which isn’t great if all you want is use Nix shells as development environments.

So for us, having a fork allows us to backport these fixes and so if you try to install RStudio using the latest available date, which is "2025-02-10", it’s going to work, whereas if you tried to build it on that date using upstream nixpkgs you’d be facing an error!

We spent quite some time backporting fixes: we went back all the way to 2019. The way this works, is that we start by checking out a nixpkgs commit on selected dates, then we “update” the R packages set by using the Posit CRAN and Bioconductor daily snapshots. Then, we backport as many fixes as possible, and ensure that a selection of popular packages work on both x86-linux (which includes Windows, through WSL) and aarch64-darwin (the M-series of Macs). Then we commit everything to a dated branch of the rstats-on-nix/nixpkgs fork. You can check out all the available dates by running: rix::available_dates(). We’re pretty confindent that you should not face any issues when using Nix to build reproducible environments for R. However, should you face a problem, don’t hesitate to open an issue!

We have now packages and R versions working on Linux and macOS from March 2019 to now. See this repository that contains the scripts that allowed us to do it. Backporting fixes was especially important for Apple Silicon computers, as it took some time for this platform to work correctly on Nix. By backporting fixes, we can now provide olders versions of these packages for Apple Silicon as well!

Using this approach, our fork now contains many more versions of working R packages than upstream. {rix} will thus likely keep pointing towards our fork in the future, and not upstream anymore. This should provide a much better user experience. An issue with our fork though, is that by backporting fixes, we essentially create new Nix packages that are not included in upstream, and thus, these are not built by Hydra, Nix’s CI platform which builds binary packages. In practice this means that anyone using our fork will have to compile many packages from source. Now this is pretty bad, as building packages from source takes quite some time. But fear not, because thanks to Cachix we now also have a dedicated binary cache of packages that complements the default, public Nix cache! We provide instructions on how to use Cachix, it’s very easy, it’s just running 2 additional commands after installing Nix. Using Cachix speeds up the installation process of packages tremendously. I want to give my heartfelt thanks to Domen Kožar for sponsoring the cache!

Another thing we do with our fork is run an action every day at midnight, that monitors the health of the R packages set. Of course, we don’t build every CRAN package, merely a handful, but these are among the most popular or the most at-risk of being in a broken state. See here.

Also, there’s a new rix release on CRAN

{rix} now handles remote packages that have remote dependencies (themselves with remote dependencies) much better thanks to code by Michael Heming.

We also spent quite some time making {rix} work better with IDEs and have also documented that in a new vignette. The difference with previous releases of {rix}, is that now when a user supplies an IDE name to the ide argument of the rix() function, that IDE will get installed by Nix, which was previously not the case. This only really affects VS Code, as before, setting ide = "code" would only add the {languageserver} server package to the list of R packages to install. That was confusing, because if ide = "rstudio", then RStudio would be installed. So we decided that if ide = "some editor", then that editor should be installed by Nix. The vignette linked above explains in great detail how you can configure your editor to work with Nix shells.

If you decide to give {rix} a try, please let us know how it goes!

Intro

I have this package on CRAN called {chronicler} and last month I got an email from CRAN telling me that building the package was failing, and I had two weeks to fix it.

I immediately thought that some dependency that my package depends on got updated, and somehow broke something. But when I checked the results of the build, I was surprised, to say the least:

How come my package was only failing on Fedora? Now that was really weird. There was no way this was right. Also, I couldn’t reproduce this bug on my local machine… but I could reproduce it on Github Actions, on Ubuntu (but it was ok on CRAN’s Debian which is really close to Ubuntu!), but couldn’t reproduce it either on Windows! What was going on? So I started digging, and my first idea was to look at the list of packages that got released on CRAN on that day (March 12th 2024) or just before, and saw something that caught my eye: a new version of {tidyselect} had just been released and even though my package doesn’t directly depend on it, I knew that this package was likely a dependency of some direct dependency of {chronicler}. So I looked into the release notes, and there it was:

* `eval_select()` out-of-bounds errors now use the verb "select" rather than
  "subset" in the error message for consistency with `dplyr::select()` (#271).

I knew this was what I was looking for, because the unit test that was failing to pass was a test that should error because dplyr::select() was being used on a column that didn’t exist. So the success of that test was defined as finding the following error message in the log, which contained the word subset but now it should be select.

But why was this failing only on Fedora on CRAN and on Ubuntu on Github Actions (but ok on Debian on CRAN)? And why couldn’t I reproduce the bug on my OpenSuse Linux computer, even though I was building a bleeding edge development environment using Nix?

And then it hit me like my older brother used to.

When building packages, CRAN doesn’t seem to use pre-compiled binaries on Fedora, so packages get built from source. This means that it takes longer to test on Fedora, as packages have to be built from source, but it also means that only the very latest releases of packages get used. On other platforms, pre-compiled binaries get used if available, and because {tidyselect} had just come out that very day, older binaries of {tidyselect} were being used on these platforms, but not on Fedora. And because these older binaries didn’t include this change, the unit test was still passing successfully on there.

On Github Actions, code coverage was computed using covr::codecov() which installs the package in a temporary directory and seems to pull its dependencies directly from CRAN. Because CRAN doesn’t offer Linux binaries packages got compiled from source, hence why the test was failing there, as the very latest version of {tidyselect} was being used (btw, use Dirk Eddelbuettel’s r2u if you binaries for Ubuntu).

And on my local machine, even though I was using the latest commit of nixpkgs to have the most bleeding edge packages for my environment, I had forgotten that the R packages on nixpkgs always lag behind the CRAN releases.

This is because R packages on nixpkgs tend to get updated alongside a new release of R, and the reason is to ensure a certain level of quality. You see, the vast majority of CRAN (and Bioconductor) packages are made available through nixpkgs in a fully automated way. But some packages do require some manual intervention to work on Nix. And we only know this if we try to build these packages, but building packages requires quite a lot of resources. I go into more detail here, but in summary we can’t build CRAN packages every single day to see if everything works well, so we only rebuild the whole tree whenever there’s a new release of R. Packages get built on a CI infrastructure called Hydra, and then get cached on cache.nixos.org so whenever someone wants to install a package, a pre-built binary gets pulled from the cache instead of getting installed from source. For packages that don’t need compiling this is not that big of a time save, but for packages that do need to get compiled it is huge. Depending on which packages you want to install, if you had to build everything from source, it could potentially take hours, but if you can install pre-built binaries it’s just a matter of how quick your internet connection is.

Anyways, I went back to my fork of nixpkgs and updated the expression defining the CRAN packages myself and installed the latest versions of packages from my fork.

Before the update, this was the error message I was testing against:

and this was on version 1.2.0 of {tidyselect}:

but after the update, this was the error message:

on version 1.2.1 of {tidyselect}:

so I found the issue, and updated my unit testing accordingly, and pushed the update to CRAN. All is well that ends well, but… this made me think. I needed to have an easy way to have bleeding edge packages on hand from Nix at all moments, and so I started working on it.

Github Actions to the rescue

As described in my previous blog post updating the Nix expressions defining the R packages on nixpkgs involves running an R script that generates a Nix expression which then builds the R packages when needed. So what I did was create a Github actions that would run this R script every 6 hours, and push the changes to a branch of my nixpkgs fork. This way, I would always have the possibility to use this branch if I needed bleeding edge packages. Because this can be of interest to others, Philipp Baumann started a Github organisation hosting this fork of nixpkgs that gets updated daily which you can find here. Because this action needs to run several times a day, it should be on a schedule, but actions on a schedule can only run from master/main. But that’s not what we wanted, so instead, we are using another action, on another repository, that pushes a random file to the target repository to get the action going. You can find this repository here with complete instructions. So to summarise:

• An action on schedule runs from b-rodrigues/trigger-r-updates and pushes a file to rstats-on-nix/nixpkgs on the r-daily-source branch
• This triggers an action that updates all of nixpkgs, including R packages, and pushes all the updates to the r-daily branch (you can find it here)
• We can now use the r-daily branch to get bleeding edge R packages on Nix!

This happens without any form of testing though, so packages could be in a broken state (hey, that’s the definition of bleeding edge, after all!), and also, if anyone would like to use this fork to build a development environment, they’d have to rebuild a lot of packages from source. Again, this is because these packages are defined in a fork of nixpkgs and they don’t get built on Hydra to populate the public cache that Nix uses by default. So while this fork is interesting because it provides bleeding edges packages, using it on a day-to-day basis can be quite tedious.

And this is where Cachix comes into play.

Setting up your own binary cache on Cachix

Cachix is an amazing tool that makes it incredibly easy to set up your own cache. Simply build the packages once, and push the binaries to the cache. As long as these packages don’t get updated, they’ll get pulled from the cache instead of getting rebuilt.

So now, here is what I do with my packages: I define a default.nix file that defines a development environment that uses my fork of nixpkgs as the source for packages. For example, here is this file that defines the environment for my {rix} package. I can use this environment to work on my package, and make sure that anyone else that wants to contribute, contributes using the same environment. As you can see on line 2, the rstats-on-nix bleeding edge fork gets used:

 pkgs = import (fetchTarball "https://github.com/rstats-on-nix/nixpkgs/archive/refs/heads/r-daily.tar.gz") {};

Then, still on {rix}’s repository, I define a new action that builds this environment periodically, but using the binary cache I set up with Cachix. You can find this action here. So the r-daily branch of our nixpkgs fork gets updated every 6 hour and this environment gets updated every 12 hours, 30 minutes past the hour.

Now, every time I want to work on my package, I simply use nix-build on my computer to update the development environment. This is what I see:

copying path '/nix/store/0l0iw4hz7xvykvhsjg8nqkvyl31js96l-r-stringr-1.5.1' from 'https://b-rodrigues.cachix.org'...
copying path '/nix/store/cw3lc7b0zydsricl5155jbmldm1vcyvr-r-tibble-3.2.1' from 'https://b-rodrigues.cachix.org'...
copying path '/nix/store/y32kpp09l34cdgksnr89cyvz6p5s94z8-r-tidyselect-1.2.1' from 'https://b-rodrigues.cachix.org'...
copying path '/nix/store/sw24yx1jwy9xzq8ai5m2gzaamvyi5r0h-r-rematch2-2.1.2' from 'https://b-rodrigues.cachix.org'...
copying path '/nix/store/z6b4vii7hvl9mc53ykxrwks1lkfzgmr4-r-dplyr-1.1.4' from 'https://b-rodrigues.cachix.org'...

as you can see, packages get pulled from my cache. Packages that are already available from the usual, public, cache.nixos.org don’t get rebuilt nor cached in mine; they simply continue getting pulled directly from there. This makes using the development environment very easy, and guarantees I’m always mirroring the state of packages released on CRAN. The other interesting thing is that I can use that cache with other actions. For example, here is the action that runs the unit tests included in the package in an environment that has Nix installed on it (some unit tests need Nix to be available to run). On line 25 you can see that we install Nix and set our fork as the repository to use:

nix_path: nixpkgs=https://github.com/rstats-on-nix/nixpkgs/archive/refs/heads/r-daily.tar.gz

and just below, we set up the cache:

- uses: cachix/cachix-action@v14
  with:
    name: b-rodrigues # this is the name of my cache

By using my cache, I make sure that the test runs with the freshest possible packages, and don’t run the risk of having a test succeed on an outdated environment. And you might have noticed that I am not authenticating to Cachix: to simply pull binaries, to authentication is needed!

Cachix has a free plan of up to 5Gb which is more than enough to set up several development environments like this, and is really, really, easy to set up, and it works on your computer and on Github Actions, as shown. If you want to use this development environment to contribute to {rix}, check out the instructions on Contributing.md file.

You can use the same approach to always have development environments ready for your different projects, and I will likely add the possibility to use this fork of nixpkgs with my {rix} package.

Thanks to Philipp Baumann for nudging me into the direction of using Cachix and showing the way!

Contributing to nixpkgs

As explained in part 8, nixpkgs is “nothing but” a huge GitHub repository containing thousands of Nix expressions. These expressions are then used to actually build the software that then gets installed by Nix. For example, this is the expression for Quarto. As you can see, it starts by downloading the pre-compiled binary, and then applying “patches”. Essentially making sure that Quarto installed by Nix is able to find the other pieces installed by Nix that Quarto needs (Deno, Pandoc, Typst and so on). It then continues by installing Quarto itself (because we’re downloading a pre-compiled binary, installation consists in moving files in the right spot), finally some tests are executed (quarto check) and then some metadata is defined. Not every package is defined like this, with a single Nix expression, though. For example, individual R packages are not defined like this. Instead, every package from CRAN and Bioconductor gets built using only a handful of files that can be found here.

(By the way, you can look for packages and find their associated Nix expressions on the NixOS package search).

The way this works, is that periodically the generate-r-packages.R script is run and generates the cran-packages.nix file (and the equivalent Bioconductor files). For each package on CRAN, a line gets written in the script with the package’s name, its current version on CRAN, and very importantly its dependencies. For example, here is the line for {dplyr}:

dplyr = derive2 { name="dplyr"; version="1.1.4";
   sha256="1jsq8pj12bngy66xms486j8a65wxvyqs944q9rxkiaylsla08wyg";
   depends=[cli generics glue lifecycle magrittr pillar R6 rlang tibble tidyselect vctrs]; };

These dependencies are actually the packages that can be found in the DESCRIPTION file under Imports. cran-packages.nix (and the same goes for the Bioconductor equivalents, bioc-packages.nix, bioc-annotation-packages.nix and bioc-experiment-packages.nix) get imported in the default.nix file. In it, another file, generic-builder.nix gets also imported, which contains a function that will attempt building the package. Most of the time this succeeds, but some packages require further tweaks. Packages that have a field NeedsCompilation in their DESCRIPTION files are usually candidates for further tweaking: these packages require system-level dependencies, which are often listed under SystemRequirements (but not always, which complicates matters). For example, the {terra} package has these system requirements listed in itself DESCRIPTION file:

SystemRequirements:  C++17, GDAL (>= 2.2.3), GEOS (>= 3.4.0), PROJ (>= 4.9.3), sqlite3

so these also need to be added if we want to build them on Nix. But if we look at the line for {terra} in cran-packages.nix, this is what we see:

terra = derive2 { name="terra"; version="1.7-65"; 
  sha256="0m9s5am8l6il1q0skab614cx0qjsb1i9xcv6nm0sdzj7p9lrzkfl"; 
  depends=[Rcpp]; };

Only {Rcpp} is listed, which is a dependency, yes, but an R package dependency, not a system-level requirement. System-level requirements need to be added in the default.nix file manually. In the default.nix, you’ll find a long list of packages called packagesWithNativeBuildInputs and packagesWithBuildInputs. NativeBuildInputs and BuildInputs are Nix jargon for dependencies the package needs, at compile-time and then at run-time specifically. For example, {Rcpp} is a BuildInput of {terra}, while the system-level requirements are NativeBuildInputs (in the context of R packages though, this rarely matters. If you want more details, refer to this Gist I’ve forked).

For {terra}, this means that we need to add this line to the list {packagesWithNativeBuildInputs} (I simplified the syntax here a bit):

terra = [ gdal proj geos ];

gdal, proj and geos are the system requirements that need to be added for {terra} to build successfully on Hydra.

Hydra

Hydra is a tool for continuous integration testing and software release that uses a purely functional language to describe build jobs and their dependencies (source: the Hydra Manual)

If you’re coming from R, think of Hydra as R-hub, which will check and build your R package before submitting to CRAN. Hydra periodically tries to rebuild packages. If that package fails, then the log gets hosted. When it comes to R packages, we can check which packages built successfully or not on here.

As of writing, the latest evaluation was in mid-January. A new release of R is going to get released on the 29th of February (or maybe was already released, I’m not sure when this blog post is going to get posted), and this is when new evaluations will likely be executed. Evaluations are the processes by which Nix expressions get… evaluated and used to actually build packages. So if we look into the results of the evaluation of the 17th of January, we see that 757 jobs failed:

One job doesn’t strictly correspond to one package though: packages get built for different architectures, and each architecture gets its build process. If we log into the details of the first package whose build failed {AIUQ}, we see this:

From the log we see that actually what failed one of its dependencies, {SuperGauss}, so fixing {SuperGauss} will likely fix {AIUQ} (I say likely because maybe another needed dependency also fails). So we could try to fix {SuperGauss} first. Let’s see why {SuperGauss}, by clicking on raw:

Here is what we see:

Running phase: unpackPhase
unpacking source archive /nix/store/615bdvjchxrd7wp5m7dhg4g04yv7ncza-SuperGauss_2.0.3.tar.gz
source root is SuperGauss
setting SOURCE_DATE_EPOCH to timestamp 1645735202 of file SuperGauss/MD5
Running phase: patchPhase
Running phase: updateAutotoolsGnuConfigScriptsPhase
Running phase: configurePhase
Running phase: buildPhase
Running phase: checkPhase
Running phase: installPhase
* installing *source* package 'SuperGauss' ...
** package 'SuperGauss' successfully unpacked and MD5 sums checked
** using staged installation
checking for gcc... /nix/store/xq8920m5mbd83vdlydwli7qsh67gfm5v-gcc-wrapper-13.2.0/bin/cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /nix/store/xq8920m5mbd83vdlydwli7qsh67gfm5v-gcc-wrapper-13.2.0/bin/cc accepts -g... yes
checking for /nix/store/xq8920m5mbd83vdlydwli7qsh67gfm5v-gcc-wrapper-13.2.0/bin/cc option to accept ISO C89... none needed
checking for pkg-config... no
checking for FFTW... configure: error: in `/build/SuperGauss':
configure: error: The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables FFTW_CFLAGS
and FFTW_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://pkg-config.freedesktop.org/>.
See `config.log' for more details
ERROR: configuration failed for package 'SuperGauss'
* removing '/nix/store/jxv5p85x24xmfcnifw2ibvx9jhk9f2w4-r-SuperGauss-2.0.3/library/SuperGauss'

This is essentially what we would see if we tried to install {SuperGauss} on Linux. The error message is quite clear here: a system-level dependency, pkg-config is missing. Looks like we found our first package to fix!

Fixing a package

The first step is to fork and clone the nixpkgs GitHub repository to your computer (be patient, the repository is huge so the download will take some time):

git clone git@github.com:b-rodrigues/nixpkgs.git

It’s also a good idea to add the original nixpkgs as an upstream:

git remote add upstream https://github.com/NixOS/nixpkgs

This way, you can pull changes from the original nixpkgs repository into your fork easily with:

git fetch upstream master
git merge upstream/master

These two commands synchronize your local copy of the repository with upstream. So now we can create a new branch to try to fix {SuperGauss}:

git branch -b fix_supergauss

and then we should try to build {SuperGauss} locally. This is because it might have been fixed in the meantime by someone else, so let’s try to build it with (run the following command in a terminal at the root of your local copy of the nixpkgs repository):

nix-build -A rPackages.SuperGauss

but I often prefer to use this instead, because this will build the package and drop me into a shell where I can start R, load the package, and try it by running some of its examples:

nix-shell -I nixpkgs=/path/to/my/nixpkgs -p rPackages.SuperGauss R

If any of the commands above fail with the same error message as on Hydra, we know that it hasn’t been fixed yet. So the fix consists in opening the pkgs/development/r-modules/default.nix and add the following line:

SuperGauss = [ pkg-config ];

in either the lists packagesWithBuildInputs or packagesWithNativeBuildInputs (as explained above, it doesn’t really matter). Trying to rebuild SuperGauss again will result in a new error message. Another dependecy needs to be added:

SuperGauss = [ pkg-config fftw.dev ];

Then, building succeeds! We can now commit, push, and open a pull request. Commit messages need to be formatted in a certain way, as per nixpkgs contributing guide, so:

git add .
git commit -m "rPackages.SuperGauss: add dependencies"

also, there should only be one commit per fix. So if in the process of fixing a package you commited several times, you will need to use git rebase to squash all the commits into one. Once you open the pull request, a maintainer will get pinged, and merge the PR if everything is alright (which is usually the case for these one-liners). You can see the PR for {SuperGauss} here.

The process is relatively simple once you did it once or twice, but there are some issues: there is no easy way to find out on which packages we should focus on. For example, is {SuperGauss} really that important? The fix was very simple, so it’s ok, but if it took more effort, should we spend the limited time we have on it, or should we focus on another package? Also, if someone has already opened a PR to fix a package, but that PR hasn’t been merged yet, if I try to also fix the same package and try to build the package, it would still fail. So I might think that no one is taking care of it, and waste time duplicating efforts instead of either focusing on another package, or reviewing the open PR to accelerate the process of merging.

Discussing this with other contributors, László Kupcsik suggested we could use {packageRank} to find out which packages are getting a lot of downloads from CRAN, and so we could focus on fixing these packages first. This is a great idea and it gave me the idea to build some kind of report that would do this automatically for us, and also list opened and merged PRs so we wouldn’t risk duplicating efforts.

This report can be found here and now I’ll explain how I built it.

Which packages to fix and keeping track of PRs

So the main idea was to know on which packages to focus on. So essentially, we wanted this table:

but with {packageRank} added to it. So the first step was to scrape this table, using {rvest}. This is what you can find on lines 11 to 63 of this {targets} workflow (alongside some basic cleaning). I won’t go too much into detail, but if something’s not clear, ping me on twitter or Mastodon or even open an issue on the report’s repository.

Next I also get the reason the package failed building. So in the example from before, {AIUQ} failed because {SuperGauss} failed. On Hydra, you should be clicking to see this, but here I scrape it as well automatically, and add this information in a column called fails_because_of. This is what you can read on lines 65 to 77. I use a function called safe_get_failed_deps(), which you can find in the functions.R script on here. safe_get_failed_deps() wraps the main function, get_failed_deps(), with tryCatch(). This is because if anything goes wrong, I want my function to return NULL instead of an error, which would crash the whole pipeline.

Next, I add the packages’ rank using a function that wraps packageRank::packageRank() called safe_packageRank() on line 97.

safe_packageRank() uses tryCatch() to return NULL in case there’s an error. This is needed because packageRank() will only work on CRAN packages, but Hydra also tries to build Bioconductor packages: when these packages’ names get passed to packageRank(), an error gets returned because these are not CRAN packages:

packageRank("haha")
Error: haha: misspelled or not on CRAN/Archive.

but instead of an error that would stop the pipeline, I prefer it simply returns NULL, hence tryCatch(). Also, I compute the rank of the package listed under the fails_because_of column and not the package column. If we go back to our example from before, {AIUQ} failed because {SuperGauss} failed, I’m actually interested in the rank of {SuperGauss}, and not {AIUQ} (which I way I went to all the trouble to scrape the failing dependency).

So, for now, when comparing to the table on Hydra, we have two further columns with the dependency that actually fails (or not, if the package fails on its own and not because of a dependency), and the rank of either the dependency that fails or the package itself.

Next, I’d like to see if PRs have already been opened and merged. For this, I use the gh tool, which is a command line tool to interact with GitHub repositories. I wrote the get_prs() wrapper around gh to list the opened or the merged PRs of the nixpkgs repository. This is what it looks like (and is defined here):

get_prs <- function(state){

  output_path <- paste0(state, "_prs.json")

  # Run the command
  system(paste0(
    "gh pr list --state=", state,
    " --search=rPackages -R NixOS/nixpkgs --json title,updatedAt,url > ",
    output_path
  ))

  # Return path for targets
  output_path
}

Because the PRs follow the contributing guidelines, I can easily process the PRs titles to get the name of the package (I essentially need to go from the string “rPackages.SuperGauss: fixing build” to “SuperGauss”) using regular expressions. This is what happens in the clean_prs() function here.

Most of what follows is merging the right data frames and ensuring that I have something clean to show. Finally, an .Rmd document gets compiled, which you can find here. This will get compiled to an .html file which is what you see when you click here.

This runs every day at midnight using GitHub actions (the workflow is here) and then I use the raw.githack.com here to serve the rendered HTML file. So every time I push, or at midnight, the action runs, computes the package rank, checks if new PRs are available or have been merged, and the rendered file is immediately available. How’s that for serverless CI/CD?

If you are interested in using Nix to make your analyses reproducible, check out the other blog posts in this series and join our small but motivated community of R contributors to nixpkgs on Matrix. If you are interested in the history of Nix, checkout this super interesting blog post by Blair Fix.

If you’re interested into using project-specific, and reproducible development environments, give {rix} and Nix a try! Learn more about {rix} on its Github repository here or website. We wrote many vignettes that are conveniently numbered, so don’t hesitate to get started!

Thanks to the colleagues of the Matrix nixpkgs R channel for the fruitful discussions that helped shape this blog post and for proof-reading.

What is rix?

{rix} is an R package that leverages Nix, a powerful package manager focusing on reproducible builds. With Nix, it is possible to create project-specific environments that contain a project-specific version of R and R packages (as well as other tools or languages, if needed). You can use {rix} and Nix to replace renv and Docker with one single tool. Nix is an incredibly useful piece of software for ensuring reproducibility of projects, in research or otherwise, or for running web applications like Shiny apps or plumber APIs in a controlled environment. The advantage of using Nix over Docker is that the environments that you define using Nix are not isolated from the rest of your machine: you can still access files and other tools installed on your computer.

For example, here is how you could use {rix} to generate a file called default.nix, which can then be used by Nix to actually build that environment for you:

library(rix)

path_default_nix <- tempdir()

rix(r_ver = "latest",
    r_pkgs = c("dplyr", "ggplot2"),
    system_pkgs = NULL,
    git_pkgs = NULL,
    ide = "code",
    shell_hook = NULL,
    project_path = path_default_nix,
    overwrite = TRUE,
    print = TRUE)

## # This file was generated by the {rix} R package v0.5.1.9000 on 2024-02-02
## # with following call:
## # >rix(r_ver = "5ad9903c16126a7d949101687af0aa589b1d7d3d",
## #  > r_pkgs = c("dplyr",
## #  > "ggplot2"),
## #  > system_pkgs = NULL,
## #  > git_pkgs = NULL,
## #  > ide = "code",
## #  > project_path = path_default_nix,
## #  > overwrite = TRUE,
## #  > print = TRUE,
## #  > shell_hook = NULL)
## # It uses nixpkgs' revision 5ad9903c16126a7d949101687af0aa589b1d7d3d for reproducibility purposes
## # which will install R version latest
## # Report any issues to https://github.com/b-rodrigues/rix
## let
##  pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/5ad9903c16126a7d949101687af0aa589b1d7d3d.tar.gz") {};
##  rpkgs = builtins.attrValues {
##   inherit (pkgs.rPackages) dplyr ggplot2 languageserver;
## };
##    system_packages = builtins.attrValues {
##   inherit (pkgs) R glibcLocales nix ;
## };
##   in
##   pkgs.mkShell {
##     LOCALE_ARCHIVE = if pkgs.system == "x86_64-linux" then  "${pkgs.glibcLocales}/lib/locale/locale-archive" else "";
##     LANG = "en_US.UTF-8";
##     LC_ALL = "en_US.UTF-8";
##     LC_TIME = "en_US.UTF-8";
##     LC_MONETARY = "en_US.UTF-8";
##     LC_PAPER = "en_US.UTF-8";
##     LC_MEASUREMENT = "en_US.UTF-8";
## 
##     buildInputs = [  rpkgs  system_packages  ];
##       
##   }

You don’t need to have Nix installed to use {rix} and generate this expression! This is especially useful if you want to generate an expression that should then be used in a CI/CD environment for example.

But if you do have Nix installed, then you can use two great functions that Philipp implemented, which we are really excited to tell you about!

nix_build() and with_nix()

When you have a default.nix file that was generated by rix::rix(), and if you have Nix installed on your system, you can build the corresponding environment using the command line tool nix-build. But you can also build that environment straight from an R session, by using rix::nix_build()!

But the reason nix_build() is really useful, is because it gets called by with_nix(). with_nix() is a very interesting function, because it allows you to evaluate a single function within a so-called subshell. That subshell can have a whole other version of R and R packages than your main session, and you can use it to execute an arbitrary function (or a whole, complex expression), and then get the result back into your main session. You could use older versions of packages to get a result that might not be possible to get in a current version. Consider the following example: on a recent version of {stringr}, stringr::str_subset(c(““,”a”), ““) results in an error, but older versions would return ”a”. Returning an error is actually what this should do, but hey, if you have code that relies on that old behaviour you can now execute that old code within a subshell that contains that older version of {stringr}. Start by creating a folder to contain everything needed for your subshell:

path_env_stringr <- file.path(".", "_env_stringr_1.4.1")

Then, it is advised to use rix::rix_init() to generate an .Rprofile for that subshell, which sets a number of environment variables. This way, when the R session in that subshell starts, we don’t have any interference between that subshell and the main R session, as the R packages that must be available to the subshell are only taken from the Nix store. The Nix store is where software installed by Nix is… stored, and we don’t want R to be confused and go look for R packages in the user’s library, which could happen without this specific .Rprofile file:

rix_init(
  project_path = path_env_stringr,
  rprofile_action = "overwrite",
  message_type = "simple"
)

## 
## ### Bootstrapping isolated, project-specific, and runtime-pure R setup via Nix ###
## 
## ==> Created isolated nix-R project folder:
##  /home/cbrunos/six_to/dev_env/b-rodrigues.github.com/content/blog/_env_stringr_1.4.1 
## ==> R session running via Nix (nixpkgs)
## * R session not running from RStudio
## ==> Added `.Rprofile` file and code lines for new R sessions launched from:
## /home/cbrunos/six_to/dev_env/b-rodrigues.github.com/content/blog/_env_stringr_1.4.1
## 
## * Added the location of the Nix store to `PATH` environmental variable for new R sessions on host/docker RStudio:
## /nix/var/nix/profiles/default/bin

We now generate the default.nix file for that subshell:

rix(
  r_ver = "latest",
  r_pkgs = "stringr@1.4.1",
  overwrite = TRUE,
  project_path = path_env_stringr
)

Notice how we use the latest version of R (we could have used any other), but {stringr} on version 1.4.1. Finally, we use with_nix() to evaluate stringr::str_subset(c(““,”a”), ““) inside that subshell:

out_nix_stringr <- with_nix(
  expr = function() stringr::str_subset(c("", "a"), ""),
  program = "R",
  exec_mode = "non-blocking",
  project_path = path_env_stringr,
  message_type = "simple"
)

## * R session not running from RStudio
## ### Prepare to exchange arguments and globals for `expr` between the host and Nix R sessions ###
## * checking code in `expr` for potential problems:
##  `codetools::checkUsage(fun = expr)`
## 
## * checking code in `expr` for potential problems:
## 
## * checking code in `globals_exprs` for potential problems:
## 
## ==> Running deparsed expression via `nix-shell` in non-blocking mode:
## 
## 
## ==> Process ID (PID) is 19688.
## ==> Receiving stdout and stderr streams...
## 
## ==> `expr` succeeded!
## ### Finished code evaluation in `nix-shell` ###
## 
## * Evaluating `expr` in `nix-shell` returns:
## [1] "a"

Finally, we can check if the result is really “a” or not:

identical("a", out_nix_stringr)

## [1] TRUE

with_nix() should work whether you installed your main R session using Nix, or not, but we’re not sure this is true for Windows (or rather, WSL2): we don’t have a Windows license to test this on Windows, so if you’re on Windows and use WSL2 and want to test this, we would be very happy to hear from you!

If you’re interested into using project-specific, and reproducible development environments, give {rix} and Nix a try! Learn more about {rix} on its Github repository here or website. We wrote many vignettes that are conveniently numbered, so don’t hesitate to get started!