lazyeval dependency breaks installation on R-devel (PREXPR removed from R C API)

[ehrlinger]

I've been working on some internal packages that take a dependecy on ggalluvial. My CI pipelines are failing on the devel pipelines and I used an AI to help me debug those errors.

ggalluvial lists lazyeval in its Imports, and lazyeval 0.2.2 (the current CRAN release) uses the C-level PREXPR symbol that has been removed from R-devel's C API. This causes lazyeval — and therefore ggalluvial — to fail to compile from source on R-devel.

Error from CI (R-devel, pak lockfile install):

Error in lazyeval_install / compilation:
'PREXPR' was not declared in this scope

Why this matters: lazyeval has been superseded by rlang and has not been updated since ~2019. It will not be fixed upstream. Packages that still import it will begin failing R CMD check on R-devel as R 4.6/next moves toward release.

Suggested fix: Replace the lazyeval import with rlang equivalents. In practice, lazyeval::lazy_eval() → rlang::eval_tidy(), lazyeval::lazy() → rlang::quo() / rlang::enquo(). Since ggalluvial already depends on ggplot2 which in turn depends on rlang, no new dependency is added — it's already in the transitive closure.

Downstream impact: Packages depending on ggalluvial (such as my internal packages) cannot pass R-devel CI without adding continue-on-error workarounds for the R-devel matrix entry.

[corybrunson]

Hi @ehrlinger and thanks for raising the issue! I was not aware that {lazyeval} had been retired. Could you check whether these changes in the lazyeval branch resolve the issue on your end?

Please also convey the following feedback to your AI:

• The only use of {lazyeval} in {ggalluvial} was lazyeval::lazy_dots(), a substitution for which was not among those provided.
• {ggalluvial} already imports {rlang}, so the comment about new dependencies was unnecessary.

[ehrlinger]

Thanks for the response. I'm investigating HOW to test your patch, since the error surfaced in my GitHub actions testing the R devel targets. I will responde with results when I figure out how to unravel THAT.

Re feedback to my AI:

• My AI apologizes for the noise around {rlang} imports.
• It still suggests an {rlang} replacement for the {lazyeval::lazy_dots()} call, {rlang::enquos(...)}

The suggested patch didn't cover this case. The rlang equivalent is rlang::enquos(...), which captures the dots as a list of quosures (unevaluated expressions with their evaluation environments).

The downstream usage typically needs updating too — lazyeval lazy objects were accessed via lazy$expr and evaluated with lazyeval::lazy_eval(), whereas rlang quosures are accessed with rlang::quo_get_expr() and evaluated with rlang::eval_tidy(). The exact swap depends on how dots is used after capture, so the maintainer will need to trace those call sites.

I realize this may be a "lazy path to providing feedback", but it seems to me converting lazyeval to rlang may be safer long term because of the "superceded" comment above.

[ehrlinger]

It looks to me like the lazyeval package will not compile on the future R devel platforms... and my AI agrees after evaluating the error message I recieved testing your patch.

This is the summary of the messages:

The patch still fails because lazyeval is still listed as a dependency in DESCRIPTION. On R-devel, PREXPR has been permanently removed from the C API — lazyeval 0.2.2 calls it in expr.c, lazy.c, and utils.c, so the package simply cannot be compiled at all. pak hits this when it tries to build the lockfile, before your patched R code even gets a chance to load. The fix needs two things: replace all lazyeval calls in R code (including lazy_dots() → rlang::enquos()), and remove lazyeval from DESCRIPTION entirely so pak never attempts to install it as a transitive dependency.

To be clear, the package installs fine on the current workflow actions, it's only the devel targets that fail. I think this means it won't be a problem now, tho CRAN will complain on the devel platforms.

[corybrunson]

Hm—in the branch i tried rlang::quo() rather than rlang::enquo() since they produced the same results on a couple of examples and the tests threw no errors after the change, but i'll pay attention in case one is preferable to the other under certain circumstances.

I think there will be no problems with downstream uses; the result of lazyeval::lazy_dots() are used only to determine which recognized arguments are passed versus left NULL. (There's probably a still more elegant way to do this.)