Repository navigation
[Dev] Pre-commit fails if R is not installed #46646
Description
Describe the bug, including details regarding any error messages, version, and platform.
I believe #46581 introduced a bug where if a developer does not have R installed on their system, the pre-commit check will fail with an exception like:
[INFO] Installing environment for local.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: CalledProcessError: command: ('Rscript', '--vanilla', '/tmp/tmp6h7jqkbh/script.R')
return code: 1
stdout:
Executable `Rscript` not found
Component(s)
Developer Tools
Activity
WillAyd commentedon May 30, 2025
I believe there are some R pre-commit hooks at https://github.com/lorenzwalthert/precommit - can these be used instead of a local hook?
kou commentedon May 31, 2025
It's an expected behavior.
If you don't want to require R, could you use
pre-commit run --show-diff-on-failure --color=always --all-files cppor something? (The lastcppis the important part. See also #46602.)It also uses local R. (We can't use it because it doesn't install cyclocomp. See also the PR description in #46581.)
WillAyd commentedon Jul 9, 2025
Trying this out on a new system, once R is installed you also need to be sure to install libxml2-dev to make pre-commit rules for R happy, and then need to install ruby-dev for subsequent rules
[-]Pre-commit fails if R is not installed[/-][+][Dev] Pre-commit fails if R is not installed[/+]amoeba commentedon Jul 11, 2025
I understand @WillAyd's perspective here. It'd be nice if all checks were entirely self-bootstrapped.
Imagine I'm a contributer who wants to contribute a PyArrow documentation change and I want to use pre-commit to make sure my change is well-formatted. I do this,
pre-commit installAt this point, I'll run into the errors @WillAyd reported (no Rscript, no ruby, no ruby dev headers). This is a bit of a disincentive for contributors to use pre-commit.
The R situation can be fully or partially resolved by migrating to Air but I'm not sure about the Ruby bit.
Is the best we can do right now just to document this?
thisisnic commentedon Oct 28, 2025
I tracked the source of the problem down in #47937 after facing a similar issue.
I agree with @amoeba that we should document this, and not suggest that new contributors use pre-commit if we can't configure it to not need everything.
jorisvandenbossche commentedon Apr 9, 2026
It would be nice to find a better solution for this, because IMO we should definitely be able to recommend contributors ot use pre-commit, but the current failures are quite confusing and annoying (even for a not-new contributor ;))
(and even when R is installed, there is still the issue from #47997)
amoeba commentedon Apr 9, 2026
I wonder if we could replace our use of lintr with jarl which is a new R linter that has a Python-based pre-commit hook: https://github.com/etiennebacher/jarl-pre-commit. I'm not sure if it's a drop-in replacement yet. But if so, we could drop the R requirement entirely from the pre-commit setup. @thisisnic what do you think?
PS: I filed #49701 to simplify the other R pre-commit check a bit.
thisisnic commentedon Apr 9, 2026
As long as we get the same behaviour and checks (or all of those that matter) I'm totally in, though I haven't looked into it.
jorisvandenbossche commentedon Aug 11, 2026
I ran into this again and getting annoyed by it. Updating the pre-commit configuration would be a rather easy change, but since I am not using R, I can't evaluate to what extent jarl is a good-enough (for our purposes) replacement of lintr.
Asked an LLM, and it says (specifically for our repo):
But it's not a full drop-in replacement for what r/.lintr currently configures:
cyclocomp_linter(26)— jarl has no cyclomatic-complexity rule at all, by design. This check would simply disappear, and since lintr is the only place it runs today (no separate CI step), that's a real loss of coverage, not just a local-dev convenience fix.object_length_linter(40)— no jarl equivalent either.line_length_linter(120)— not in jarl (it deliberately punts all formatting concerns to Air) — but this one's already redundant, since r/air.toml already sets line-width = 120 and Air already runs as a pre-commit hook.object_name_linter,return_linter,indentation_linter,object_usage_linterare already disabled (NULL) in r/.lintr, so nothing lost there.assignment,true_false_symbol,seq,equals_na,browser, etc.) but it's not a guaranteed 1:1 mapping — would need a closer audit.lintr/cyclocomp(r/vignettes/developers/workflow.Rmd, docs/source/developers/guide/step_by_step/styling.rst) would need updating.So: eliminating the hard R dependency is easy and safe. Fully "replacing lintr" cleanly drops complexity/name-length checks with no substitute — that's the real trade-off, not the YAML change itself.
Do the R devs think that would be fine?
eitsupi commentedon Aug 12, 2026
Could this actually be a limitation of pre-commit rather than lintr itself?
My understanding is that pre-commit may still provision a hook's environment even when no files matching that hook were changed.
If so, requiring R for contributors who are not touching the R code would be a consequence of the hook-management model, and perhaps a sign that pre-commit is not an ideal fit for this particular monorepo use case.
Have alternatives such as lefthook been considered?
Tools in that category typically invoke already-installed commands only when relevant files are involved.
I think using jarl can still make sense for other reasons.
I am just not sure that avoiding an additional non-Python toolchain dependency is, by itself, the right way to frame this particular problem.
jorisvandenbossche commentedon Aug 12, 2026
This is definitely a limitation of pre-commit. See also #47937 where this was discussed in context of a hook that requires ruby locally, and I think the conclusion of @thisisnic is that it is not easy to avoid installing all hooks regardless of which files are touched.
And indeed for a mono-repo with many different languages, we are running into that limitation ..
But switching to something else is even a bigger change (probably), and so as long as we are using pre-commit, I feel that "the hook should install out of the box on most machines" as a rule would be useful to keep this contributor-friendly.
Because otherwise, I would actually propose to simply drop those hooks from pre-commit. We don't need pre-commit for CI, where we can easily run the specific linter directly (as we did in the past, although maybe through archery), I think the most value of pre-commit is for the local contributor.
jorisvandenbossche commentedon Aug 12, 2026
(FWIW, if we consider moving away from
pre-commit, thenprekis also an option, which is a more 1:1 replacement, but also mentions to better support mono-repos with their workspace concept https://prek.j178.dev/workspace/, but didn't actually check if that avoids installing all the hooks)GH-46646: [dev][R] Replace linr with jarl for R linting / pre-commit …
thisisnic commentedon Aug 21, 2026
Issue resolved by pull request 50851
#50851