DOC: rpy2 examples started failing

[jorisvandenbossche]

The rpy2 examples in the documentation started failing recently (http://pandas-docs.github.io/pandas-docs-travis/r_interface.html) with:

In [1]: from rpy2.robjects import r, pandas2ri
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-79b90b86f23f> in <module>()
----> 1 from rpy2.robjects import r, pandas2ri

~/miniconda3/envs/pandas/lib/python3.6/site-packages/rpy2/robjects/__init__.py in <module>()
     14 import itertools
     15 from datetime import datetime
---> 16 import rpy2.rinterface as rinterface
     17 import rpy2.rlike.container as rlc
     18 

~/miniconda3/envs/pandas/lib/python3.6/site-packages/rpy2/rinterface/__init__.py in <module>()
     48 del(os)
     49 
---> 50 from rpy2.rinterface._rinterface import (baseenv,
     51                                          emptyenv,
     52                                          endr,

ImportError: dlopen: cannot load any more object with static TLS

However, I don't see any change in version between a recent working build and the current failing (this working one uses rpy2 2.9.1-py36mro343h14c3975_0, and this failing one 2.9.1-py36mro343h14c3975_0, so the same)

Could this be caused by installing another library?

cc @lgautier

[WillAyd]

Hmm this has been inconsistent right? Googling the error I saw a few other issues for other projects but none seemed to have a definite resolution. Here's something similar from Tensorflow:

tensorflow/models#523

A lot of the answers seemed to be doing things that "fixed" the issue without any explanation (ex: changing import order) or just restarting the system...

[jorisvandenbossche]

I think is has been rather consistently failing since some time.
But indeed, I also googled and only found such not very helpful issues as you describe ..

[TomAugspurger]

Reproduced locally from docker's base image.

Haven't narrowed things down yet. Pushing to the next release.

[datapythonista]

Looks like this is failing even more than when the issue was created. We don't even have the required modules in the dependencies we use to build the docs:

https://pandas.pydata.org/pandas-docs/stable/r_interface.html

As the functionality being documented is not on pandas but on rpy2, and nobody complained about the page giving errors everywhere, what I'd do is simply remove the page from the docs. One of the reasons I think it's better to delete the page instead of fixing the problem, is that fixing the problem implies installing more than 50 additional dependencies (required by rpy2) in the builds and in our local development environments.

Does this sound reasonable?

[jorisvandenbossche]

The error you see in the stable docs is "fixed" by #22424 (and this was also backported to the 0.23.x branch, but we never released again). So in the dev build it is back to the above error: http://pandas-docs.github.io/pandas-docs-travis/r_interface.html), and @TomAugspurger has a working environment locally to built them correctly, but I suppose he never uploaded updated docs: #22777 (comment)

So I think it is possible to have correctly built docs online (the doc were also correct up to 0.23.3, only started failing from 0.23.4).

That said, I am certainly not against removing it from our doc build (whether it is removing completely, or just removing the fact that the examples are run during the doc build)

[datapythonista]

I opened the PR #23737 removing it, so we can see what's the impact while we make a decision. I think moving the examples from ipython blocks to regular code blocks is a good idea too. But personally I think that page is documenting rpy2 (another package) and not pandas, and feels to me like if we start adding dask examples to our documentation. So my preferred option is still delete the page.

To give more context, these are the additional dependencies that we need for rpy2:

    _r-mutex:               1.0.0-mro_2                r          
    binutils_impl_linux-64: 2.31.1-h6176602_1                     
    binutils_linux-64:      2.31.1-h6176602_3                     
    cairo:                  1.14.12-h8948797_3                    
    curl:                   7.62.0-h74213dd_0          conda-forge
    fribidi:                1.0.5-h7b6447c_0                      
    gcc_impl_linux-64:      7.3.0-habb00fd_1                      
    gcc_linux-64:           7.3.0-h553295d_3                      
    gfortran_impl_linux-64: 7.3.0-hdf63c60_1                      
    gfortran_linux-64:      7.3.0-h553295d_3                      
    graphite2:              1.3.12-hfc679d8_1          conda-forge
    gxx_impl_linux-64:      7.3.0-hdf63c60_1                      
    gxx_linux-64:           7.3.0-h553295d_3                      
    harfbuzz:               1.9.0-h04dbb29_1           conda-forge
    krb5:                   1.16.2-hbb41f41_0          conda-forge
    libcurl:                7.62.0-hbdb9355_0          conda-forge
    libssh2:                1.8.0-h5b517e9_2           conda-forge
    make:                   4.2.1-h470a237_1002        conda-forge
    mro-base:               3.5.1-3                    r          
    mro-base_impl:          3.5.1-h9a62091_0           r          
    pango:                  1.42.4-h049681c_0                     
    pixman:                 0.34.0-h470a237_3          conda-forge
    r-assertthat:           0.2.0-mro351hf348343_0     r          
    r-bh:                   1.66.0_1-mro351hf348343_0  r          
    r-bindr:                0.1.1-mro351hf348343_0     r          
    r-bindrcpp:             0.2.2-mro351hebc1506_0     r          
    r-bit:                  1.1_14-mro351hd10c6a6_0    r          
    r-bit64:                0.9_7-mro351hd10c6a6_0     r          
    r-blob:                 1.1.1-mro351hf348343_0     r          
    r-cli:                  1.0.0-mro351hf348343_0     r          
    r-crayon:               1.3.4-mro351hf348343_0     r          
    r-dbi:                  1.0.0-mro351hf348343_0     r          
    r-dbplyr:               1.2.2-mro351hf348343_0     r          
    r-digest:               0.6.15-mro351hd10c6a6_0    r          
    r-dplyr:                0.7.6-mro351hebc1506_0     r          
    r-fansi:                0.2.3-mro351hd10c6a6_0     r          
    r-glue:                 1.3.0-mro351hd10c6a6_0     r          
    r-magrittr:             1.5-mro351hf348343_0       r          
    r-memoise:              1.1.0-mro351hf348343_0     r          
    r-pillar:               1.3.0-mro351hf348343_0     r          
    r-pkgconfig:            2.0.1-mro351hf348343_0     r          
    r-plogr:                0.2.0-mro351hf348343_0     r          
    r-prettyunits:          1.0.2-mro351hf348343_0     r          
    r-purrr:                0.2.5-mro351hd10c6a6_0     r          
    r-r6:                   2.2.2-mro351hf348343_0     r          
    r-rcpp:                 0.12.18-mro351hebc1506_0   r          
    r-revoutils:            11.0.0-mro351_0            r          
    r-revoutilsmath:        11.0.0-mro351_0            r          
    r-rlang:                0.2.1-mro351hd10c6a6_0     r          
    r-rsqlite:              2.1.1-mro351hebc1506_0     r          
    r-tibble:               1.4.2-mro351hd10c6a6_0     r          
    r-tidyselect:           0.2.4-mro351hebc1506_0     r          
    r-utf8:                 1.1.4-mro351hd10c6a6_0     r          
    rpy2:                   2.9.4-py36mro351h6853232_0 r   

[jorisvandenbossche]

Simply converting it to plain code-blocks and removing the packages from the doc build environment is certainly good for me.

But personally I think that page is documenting rpy2 (another package) and not pandas, and feels to me like if we start adding dask examples to our documentation. So my preferred option is still delete the page.

Historically, the reason that I wanted to keep this page and put some effort in it to update it when we removed the interface included in pandas, is because the rpy2 docs itself don't really mention it (I would personally think that the pandas <-> R interaction should be one of their selling points, but that is clearly not the case at this point).
For example, if we remove the page, I think it would be good in the beginning to still keep the url working but redirect / point to a page in the rpy2 docs, but I didn't find such a page (and I am not going to do a PR to rpy2 myself, as I don't use it personally).

[TomAugspurger]

I'm fine with converting them to code blocks. I was able to reproduce the import error within a docker container. Never able to fix it though.

…

On Fri, Nov 16, 2018 at 4:54 AM Joris Van den Bossche < ***@***.***> wrote: Simply converting it to plain code-blocks and removing the packages from the doc build environment is certainly good for me. But personally I think that page is documenting rpy2 (another package) and not pandas, and feels to me like if we start adding dask examples to our documentation. So my preferred option is still delete the page. Historically, the reason that I wanted to keep this page and put some effort in it to update it when we removed the interface included in pandas, is because the rpy2 docs itself don't really mention it (I would personally think that the pandas <-> R interaction should be one of their selling points, but that is clearly not the case at this point). For example, if we remove the page, I think it would be good in the beginning to still keep the url working but redirect / point to a page in the rpy2 docs, but I didn't find such a page (and I am not going to do a PR to rpy2 myself, as I don't use it personally). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20648 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHIofEOgsLN5Qllncl_xu6pkOjkvi1ks5uvpl8gaJpZM4TOGyM> .

[datapythonista]

Ok, let's close this then.