Repository navigation
rpy2 in API mode cannot be built without R. #13796
Description
Activity
@1himan what version of
uvis installed? I cannot replicate the error on install, but I do get that same error when I try to actually run the tutorial added in #13729In any case, if this is going to be a blocker for contributors, I personally do not feel good about having an implicit R dependency to be able to build the docs. I apologize for not looking closer at #13729 or #13721 and raising my concerns then.
I'm using:
uv 0.11.1 (a6042f67f 2026-03-24 x86_64-unknown-linux-gnu).Additional info
mne sys_info Platform Linux-6.19.9-arch1-1-x86_64-with-glibc2.43 Python 3.14.3 (main, Feb 13 2026, 15:31:44) [GCC 15.2.1 20260209] Executable /usr/bin/python CPU 12th Gen Intel(R) Core(TM) i5-12450H (12 cores) Memory 15.3 GiB Core ├☑ mne 1.11.0 (latest release) ├☑ numpy 2.4.3 (unknown linalg bindings) ├☑ scipy 1.17.1 └☑ matplotlib 3.10.8 (backend=qtagg) Numerical (optional) ├☑ sklearn 1.8.0 ├☑ pandas 2.3.3 ├☑ h5io 0.2.5 ├☑ h5py 3.16.0 └☐ unavailable numba, nibabel, nilearn, dipy, openmeeg, cupy Visualization (optional) ├☑ qtpy 2.4.3 (PySide6=6.10.2) ├☑ pyqtgraph 0.14.0 ├☑ mne-qt-browser 0.7.4 └☐ unavailable pyvista, pyvistaqt, vtk, ipympl, ipywidgets, trame_client, trame_server, trame_vtk, trame_vuetify Ecosystem (optional) ├☑ edfio 0.4.13 ├☑ pybv 0.7.6 ├☑ defusedxml 0.7.1 └☐ unavailable mne-bids, mne-nirs, mne-features, mne-connectivity, mne-icalabel, mne-bids-pipeline, neo, eeglabio, curryreader, mffpy, antiookay... even with the latest version
uv --version uv 0.11.2 (x86_64-unknown-linux-gnu)
I get the same error.Ah OK I can replicate the error if I install from source (I do not have R installed on my computer either):
uv pip install --no-binary rpy2,rpy2-rinterface,rpy2-robjects rpy2 rpy2-rinterface rpy2-robjectsLooks like there aren't any published Linux wheels for
rpy2-rinterfaceon pypi, which explains why @1himan is hitting this issue when installing the docs groupEDIT: And as the message hints at, the immediate work around is to set
export RPY2_CFFI_MODE=ABII just ran into this also.
I'd say at the minimum there should be a note in the contributing guide about this potentially happening when setting up the dev environment, but better yet if there's a workaround to avoid this in the first place. Not sure what that would look like though.Discussed this with @tsbinns and @scott-huberty. Plan is for @tsbinns to add a
build_script.pyto be run by hatchling during install; that script will set the env var so that ABI mode is triggered. I think it should be unnecessary to unset afterward, as the env var will only last the duration of that shell.If that works, then we probably should also just skip installing
r-basein CIs and rely on ABI mode env var.with that sorted, we should also add some docs (to the example itself, and maybe to the contrib guide) warning that the ABI-mode env var is only a workaround for installation, and that the example will need
r-baseto be installed in order to be executed (fails withR_HOME is Noneor similar if it's not). Unfortunately, sphinx-gallery examples don't have a niceskipifmechanism like pytest does.@drammock @scott-huberty Slight hickup: I can't get the
rpy2-interface(and other) installs to stop working.I used
export RPY2_CFFI_MODE=ABIyesterday to get the doc group installed, but I can't figure out how to undo this. E.g., if I setexport RPY2_CFFI_MODE=API, it doesn't cause the error I got yesterday.I'll need to track down what's happening before I can test the fix locally.
Reacted by Daniel McCloyis it possible you somehow ended up with R installed on your system without realizing it?
@tsbinns This happened to me too -
pipwas using a cached wheel from my previously successful install (even if I passed the--no-binaryflag..)clearing the cache worked for me:
python -m pip cache remove rpy2EDIT: I guess you can also pass
--no-cache-dirflag to thepip installcommandThis is also creating a mess in mne-tools/mne-installers#427 and the ABI tweak didn't seem to fix things there when I tried it.
It is so rare for devs to want to build all doc examples nowadays... I think
devshouldn't includerpy2. By extension,docshouldn't either. I think a separatedoc-fullcould make sense here, and it could inherit thedocgroup and add any "heavy" dependencies, in this case so far probably justrpy2. In practice maybe only CircleCI will use this group, but having it inpyproject.tomlwill allow devs to see what they might want toconda installorpip installthemselves to get things working in case they want to build all examples locally (I do it maybe once a year nowadays!).Reacted by Scott Huberty...
rpy2packages for Windows are no longer being built on conda-forge:This is perhaps not surprising, since Windows isn't even mentioned in the rpy2 install docs. But this strongly suggests to me that we should not make
--group dev(or docs) include it, and just make CircleCI and the rare dev who wants to run all examples (or that particular example) jump through the necessary hoops to do it.Reacted by Scott Huberty and Himanshu MahorIs it still worth pursuing the plan to catch and fix with hatchling hooks (#13796 (comment)) if it's now in the
doc-fullgroup?
I feel like yes, since the new group won't prevent the install issue from happening, but it does add a little complexity to the install process which now very few people will likely encounter.I would vote no, not worth the added complexity anymore. People who want to use
rpy2can build and install it however they need toReacted by Thomas S. Binns
Description of the problem
After #13729 is merged, I'm getting the following build error as you can see in ss, after creating a fresh
venv:Inside the
pyproject.toml:devincludes thedocgroup, anddoccurrently includesrpy2, which requires a working R installation at build time. See this.