Error about is_character() not an exported object

[bertvandepoel]

I happened to do a new install of R 4.2 today because I needed a package that needed a newer version. While installing all my libraries, I kept running into the following error while installing ellipsis and vctrs:

Error: .onLoad failed in loadNamespace() for 'rlang', details:
  call: NULL
  error: 'is_character' is not an exported object from 'namespace:rlang'
Execution halted

Trying to go back to R 3.6 didn't help either. After doing several fresh installs that looked exactly like my previous install, I downgraded Rlang to 1.0.4 and that immediately solved all my issues with ellipsis and vctrs (though ggplot2 is not too happy it seems). I think there's some kind of regression issue happening here. While looking for a solution, I noticed someone else is having the exact same issue, also starting very recently, which further supports my suspicion this has cropped up with the new release https://twitter.com/delaBJL/status/1567131902166896641

[lionel-]

Could you do this before triggering the error:

Sys.setenv("_R_TRACE_LOADNAMESPACE_" = "4")

And give me the output please?

[delabj]

Hey, I'm the one in the twitter thread.

I'll give some extra context here. I encountered this when installing gt in a scheduled job that was running in a Domino Data Lab environment on 2022-08-01 using R 3.5. (It had run fine on 2022-08-30) Domino images are controlled by another team so I decided to try the image labeled experimental which uses R 4.0.1 and found the same issue. I was not able to recreate the error in a Sagemaker Notebook (R 4.1.3) instance nor on a local windows machine (R 4.1.2).

I also see this issue if I try to install just ellipsis. like @bertvandepoel does.

Here's a minimal reprex of the error with SI for the R 4.0.1 image I have access to: https://gist.github.com/delabj/e1617ce09903b473e8d7d8c48696b53a

Here is the accompanying console log: https://gist.github.com/delabj/32a77fd1bcf175e20dde834d63474d15

[lionel-]

Ah you need 4.1.0 to get the extra trace output.

What version of pillar do you have? What happens if you update pillar beforehand? Have you tried reinstalling all packages from scratch to their latest version?

[lionel-]

@bertvandepoel Since you can reproduce on R 4.2, it'd very useful to get that namespace-trace output.

[delabj]

What version of pillar do you have?

Currently looks to be 1.4.7

I have done a bit of of that with the trail from gt. I started with rlang and then vectors and see a similar result.

[lionel-]

Can you try to update pillar and see if it fixes it please?

[delabj]

Doing this gives this console output: https://gist.github.com/delabj/ac6f1b993db156606bc4d352520989a4

It seems to fail to update thanks to a failure to update vctrs which is failing due to something with rlang.

[lionel-]

Maybe remove vctrs and reinstall it?

(I think it'd be easier if you reinstalled everything from scratch, if possible)

[delabj]

Gave that a go. I removed all packages in this chain and re-ran the install and it works.

I did forget to mention in the thread on twitter, I was able to work around this by specifying an install of rlang 1.0.4 which has fixed the issue for the scripts being run in a non interactive environment, using the images provided to me. (I know that my situation is unique in that I don't really have control of the environment until it spins up)

[FedericoComoglio]

Same here. This is breaking CI pipelines that include package installations depending on rlang. Besides the (manual) workaround suggested above (part. downgrading to rlang 1.0.4 or re-installing the whole tool chain, which fails for me in a clean environment on R 4.1.1), how are you planning to tackle this issue? Thank you!

[lionel-]

I don't have any plans to tackle the issue yet because I don't know what's causing it.

which fails for me in a clean environment on R 4.1.1

Is this with a CRAN repo with all latest versions or this is a controlled repo with pinned versions?

[lionel-]

It'd be helpful if someone with R >= 4.1.0 could do this:

Sys.setenv("_R_TRACE_LOADNAMESPACE_" = "4")

Then trigger the error, and provide the output.

[bertvandepoel]

@bertvandepoel Since you can reproduce on R 4.2, it'd very useful to get that namespace-trace output.

I lost a full day's work because of this issue with a strict deadline next week on Tuesday, so I can only look at it after that deadline at the earliest. Sorry for the slow reply, but as you can imagine I've been scrambling to make up time.

[CyrilWendl]

I don't have any plans to tackle the issue yet because I don't know what's causing it.

which fails for me in a clean environment on R 4.1.1

Is this with a CRAN repo with all latest versions or this is a controlled repo with pinned versions?

Hi everyone - I am using an renv package environment with all the latest package versions available, from CRAN, and am getting the same error as described above. My console output looks very similar to the one linked by user delabj. Downgrading rlang to 1.0.4 is not a preferrable option for me as it will involve downgrading some other packages too. In particular, lifecycle 1.0.2 seems to depend on rlang >=1.0.5. I'd also be curious to understand what is causing this issue.

[jiho]

With a new user, with an empty R environment (i.e. no packages beyond the system installed ones), on Ubuntu 20.04 (R 4.1.2), this is the output of install.packages("vctrs") with Sys.setenv("_R_TRACE_LOADNAMESPACE_" = "4"):
https://gist.github.com/jiho/a6f347334cf6006086c22a64e0a352e5

As I understand the only workaround now is installing version 1.0.4 of rlang, right?

[jiho]

I confirm that install.packages("https://cran.r-project.org/src/contrib/Archive/rlang/rlang_1.0.4.tar.gz", repos=NULL, type="source") and then installing the rest of the stack works (with only some warnings).

[FedericoComoglio]

I confirm that the approach taken by @jiho is reproducible, with the same output on R 4.1.1 (same distro)

[bertvandepoel]

I don't have any plans to tackle the issue yet because I don't know what's causing it.

which fails for me in a clean environment on R 4.1.1

Is this with a CRAN repo with all latest versions or this is a controlled repo with pinned versions?

Hi everyone - I am using an renv package environment with all the latest package versions available, from CRAN, and am getting the same error as described above. My console output looks very similar to the one linked by user delabj. Downgrading rlang to 1.0.4 is not a preferrable option for me as it will involve downgrading some other packages too. In particular, lifecycle 1.0.2 seems to depend on rlang >=1.0.5. I'd also be curious to understand what is causing this issue.

As soon as you've installed the package running into trouble, I've found you can re-upgrade. On my working setup, what I did is I just downgraded to rlang 1.0.4 to install vctrs and ellipsis, then upgraded it to 1.0.5 and continued the rest of my install. You could try that as a workaround.

[lionel-]

This sort of errors (unexported object even though the object is exported) has two causes that I know of. In both cases it happens in the .onLoad() hook:

1. The package being loaded attempts to access one of its own functions with ::. Since .onLoad() is ran very early before the exports are populated, R can't find the exported object.

2. The package being loaded (A) triggers loading of another package (B) from .onLoad(). The package B has a user-level onload hook for A. This is set with e.g. setHook(packageEvent("pkgA", "onLoad"), my_function). When you set such a hook, you normally check that the package is not already loaded with isNamespaceLoaded() to run the hook manually, because in that case is the onload hook will never be called unless the package is unloaded and reloaded. The thing is, isNamespaceLoaded() has a bug and will return TRUE if called from the .onLoad() hook of the package in question. This means the package has not finished loading and the exports have not been populated, which may lead to the sort of issues observed here. Worth noting that we have implemented workarounds for this bug in recent versions of our packages, which is why it's important to have a fully up to date library.

@jiho's log rules out scenario 2 because the namespace trace doesn't show any package being loaded from rlang's .onLoad() hook before the error occurs.

Scenario 1 is plausible, especially since :: qualifications have been added to compat files, and there is now an rlang::is_character() check in check_character() (d785ad0).

However, I can't figure out how check_character() or even is_character() would be called from rlang's .onLoad hook. If I set debug() or trace() on is_character() on my machine (at the very start of rlang's .onLoad()), it doesn't show any usage.

@gaborcsardi Am I missing anything in my analysis?

[gaborcsardi]

IDK what could cause this, and I think our best hope to fix is to reproduce and debug it.

Btw. a possible workaround is to use --no-test-load:

install.packages("vctrs", INSTALL_opts="--no-test-load")

As for debugging it, I cannot reproduce the error with the following Dockerfile, with any R version I tried:

FROM ubuntu:20.04

RUN apt-get update && apt-get install -y curl

RUN curl -Ls https://github.com/r-lib/rig/releases/download/latest/rig-linux-latest.tar.gz | tar xz -C /usr/local

RUN echo y | rig add 4.1.2 --without-rspm

RUN R -q -e 'install.packages("vctrs")'

How did you install R?

Do you have anything in your .Rprofile? If yes, then can you try it without the profile?

[gaborcsardi]

Also could no reproduce with the CRAN R build for Ubuntu 20.04:

FROM ubuntu:20.04

RUN apt-get update

RUN apt install -y --no-install-recommends software-properties-common dirmngr wget

RUN wget -qO- https://cloud.r-project.org/bin/linux/ubuntu/marutter_pubkey.asc | tee -a /etc/apt/trusted.gpg.d/cran_ubuntu_key.asc

RUN add-apt-repository "deb https://cloud.r-project.org/bin/linux/ubuntu $(lsb_release -cs)-cran40/"

RUN apt install -y --no-install-recommends r-base

RUN apt install -y build-essential

RUN R -q -e 'install.packages("vctrs")'

[bertvandepoel]

I myself am using Ubuntu 18.04 with the CRAN40 apt repository, but I was under the impression others in this thread (at least @jiho ) had the issue on Ubuntu 20.04 too, so it's strange you can't seem to reproduce it. Could you perhaps also try ellipsis? That has been my main issue, I only ran into vctrs during trial and error trying to fix it.

[gaborcsardi]

Sure, ellipsis works fine as well.

[gaborcsardi]

And 18.04 works as well, the same Dockerfile, just changed the version number.

[delabj]

Doing the install.packages("vctrs", INSTALL_opts="--no-test-load") works for me, but only if I do the entire dependency tree as some packages in my image I'm provided are too out of date.

[gaborcsardi]

OK, I can finally reproduce this with vctrs 0.3.4:

install.packages("https://cloud.r-project.org/src/contrib/Archive/vctrs/vctrs_0.3.4.tar.gz", repos = NULL, type = "source")

[gaborcsardi]

Although vctrs 0.3.8 is required by rlang now:

Warning: The package `vctrs` (>= 0.3.8) is required as of rlang 1.0.0.

[gaborcsardi]

@lionel- If I comment out the run_on_load() call in rlang::.onLoad() then there is no error, so it is definitely something in there.

[gaborcsardi]

@lionel- Looks like is your number 2. case, from here:

  check_downstream(
    "1.0.0",
    "ellipsis (>= 0.3.2)",
    "vctrs (>= 0.3.8)",
    info = "Not updating now is completely safe and will only cause import warnings."
  )

[lionel-]

Awesome, thanks a lot @gaborcsardi! And thanks @gui-salome for your report.

As an immediate corrective measure I've fixed check_downstream() so it doesn't call rlang functions if not fully loaded. I've also removed the namespace qualifications from the compat files for safety.

In addition I'll remove the check_downstream() check. There is a bad interaction with RStudio cloud that required saving some state in the search path, in the org-r-lib environment, which Kurt noticed and asked me to remove.

I'll send a fix release to CRAN shortly.
Thanks for your reports everyone and sorry for the inconvenience!

[gaborcsardi]

I can confirm that current GH rlang fixes the issue.

[bertvandepoel]

I've set a reminder and will completely reinstall R after my deadline so I can verify this as well. Hopefully by that time (Wednesday next week) the release will already be out, otherwise I will have to figure out how to install it from GH.