feat(generate-recipe): close remaining gaps in R recipe generation

[pb01ka]

I may have made mistakes in my research - please correct me if anything below is wrong or incomplete.

Background

rattler-build generate-recipe is the only R recipe generator in the conda ecosystem that works today, targets the v1 recipe.yaml format, and uses a reliable data source. The two alternatives have both effectively stalled:

• conda skeleton cran - broken in all recent conda-build releases; requires a downgrade to v3.27.0; users are being directed away from it; refer - Monitoring grayskull support for R package recipes bgruening/conda_r_skeleton_helper#58 and specifically, Monitoring grayskull support for R package recipes bgruening/conda_r_skeleton_helper#58 (comment). Also note the correction pointed out by @isuruf feat(generate-recipe): close remaining gaps in R recipe generation #2563 (comment),

Quoting the correction,

Yes, that's a misinterpretation. 99.9% of R packages are in CRAN so R packages in github is a niche problem. conda skeleton cran is still the best way to generate R recipes.

• grayskull - active, unresolved CRAN bugs (#616, #615). AFAIK, it generates v0 meta.yaml by default; an extra conda-recipe-manager conversion step is required for v1 output. Scrapes CRAN DESCRIPTION files directly - fragile and CRAN-only. (#532)
• conda_r_skeleton_helper (bgruening) - a post-processor only; calls conda skeleton cran internally and inherits all of its brokenness.

rattler-build generate-recipe already has the right foundations:

• Queries the R-universe JSON API - structured, reliable, and covers CRAN, Bioconductor, and GitHub-hosted R packages via --universe. (cran.rs:build_cran_recipe_and_deps())
• Generates v1 recipe.yaml natively using ${{ }} Jinja syntax - the format conda-forge is migrating toward. (cran.rs:279-284)
• Detects compilation requirements via the NeedsCompilation DESCRIPTION field and LinkingTo dependencies, and inserts C/C++ compilers automatically. (#2597)
• Adds cross-r-base for cross-compilation support and sets rpaths for compiled packages. (#2597)
• Marks pure-R packages as noarch: generic automatically. (#2597)
• References r-base's bundled license texts via ${{ PREFIX }}/lib/R/share/licenses/ for standard SPDX licenses. (#2597)
• Correctly pins r-base (with version constraint from Depends: R (>= x.y.z)) in both host and run. (#2597)
• Passes ${R_ARGS} to R CMD INSTALL, matching the conda-forge convention for build-time flag injection. (#2597)
• Written in Rust - fast, no subprocess calls, no arbitrary code execution.
• Python bindings exposed via py-rattler-build (generate_cran_recipe(package, universe)). (recipe_generation.py:46)

Known gaps to address (As far as I could figure out - please correct me if I’m wrong or if there are others):

AFAICT, I have found no open issue currently tracks the following gaps.

Note: PR #2597 improved R recipe generation in several ways (cross-compilation, rpaths, noarch, license files, r-base pinning, R_ARGS) but did not address the two gaps below.

1. No conda-forge existence check for R dependencies

Impact: The generated recipe lists R dependencies by their CRAN name. If a dependency is not yet on conda-forge, the recipe will fail at solve time with no clear diagnostic.

Current behavior: cran.rs collects a remaining_deps HashSet for Imports, Depends, and LinkingTo packages but never uses it to check conda-forge availability - the set is silently dropped after dependency processing. The --tree flag only checks whether a local folder already exists, not whether the package is available on conda-forge.

Contrast with PyPI generator: pypi.rs fetches a live conda-forge name mapping from regro/cf-graph-countyfair at runtime (pypi.rs:225-228) and uses it to resolve PyPI -> conda-forge names. No equivalent exists for CRAN.

2. Suggests dependencies are commented out rather than conditionally handled

Impact: CRAN Suggests are optional test/example dependencies. The current output comments them out entirely (as # - r-foo # suggested inline in the run: block), losing structural information that downstream packagers or automated tools may need. A better default would be to emit them in a clearly marked optional section (e.g. under a run_constrained: block or a dedicated labelled comment block) so packagers know they exist and can make an informed choice.

Note: PR #2597 did not change this behavior - Suggests remain inline commented-out entries in the run: block.

TODO

• Conda-forge existence check for R deps - implement a CRAN -> conda-forge name mapping analogous to the PyPI mapping in pypi.rs. The mapping could be fetched from cf-graph-countyfair at runtime or bundled. Warn (or skip) when a dependency has no conda-forge equivalent, rather than silently discarding it. - feat: warn about R dependencies missing from conda-forge in generated recipes #2622
• Suggests handling - instead of commenting out suggested dependencies, emit them in a clearly distinguished section so downstream packagers have the full picture.
• Address feat: improve CRAN recipe generation for R packages #2597 (review) and feat: improve CRAN recipe generation for R packages #2597 (review) - fix: use skip condition and platform-split script in generated R recipes #2609

Why invest here

rattler-build generate-recipe is the best option (AFAICT) for R recipe generator that is both working and targeting the right output format. The gaps above are bounded and well-understood. Closing them would make the tool production-ready for conda-forge R packaging workflows, without the dependency on conda skeleton or the CRAN scraper in grayskull.

I would re-iterate that I might have made incorrect claims. Please feel free to point out my incorrect claims. I would update the content of my issue as per the incoming feedback/comments. Thank you so much for reading till here. <3.

[isuruf]

conda skeleton cran - broken in all recent conda-build releases; requires a downgrade to v3.27.0; users are being directed away from it.

Where's this coming from? I haven't seen any issues related to this.

[pb01ka]

As far as I remember, I reached that conclusion while reading the discussion in bgruening/conda_r_skeleton_helper#58. Specifically, bgruening/conda_r_skeleton_helper#58 (comment).

Please let me know if I misinterpreted the comments there.

[isuruf]

Yes, that's a misinterpretation. 99.9% of R packages are in CRAN so R packages in github is a niche problem. conda skeleton cran is still the best way to generate R recipes.

[wolfv]

We fixed a few of these shortcomings here: #2597

[pb01ka]

We fixed a few of these shortcomings here: #2597

TY @wolfv. I will update the issue description with the updates from your merged PR. I will list down the specific left over shortcomings and probably take those up (let me know if it sounds good to you?). TY again. :).

[wolfv]

Sounds good!

[pb01ka]

@wolfv I have added a TODO list in the issue description above. I will raise PR(s) addressing those by today EOD. Please let me know if your thoughts differ on any of the TODOs I have added. TYSM for taking a look. <3.

[isuruf]

• implement a CRAN -> conda-forge name mapping analogous to the PyPI mapping in pypi.rs. The mapping could be fetched from cf-graph-countyfair at runtime or bundled. Warn (or skip) when a dependency has no conda-forge equivalent, rather than silently discarding it.

This is unnecessary. Package foo in CRAN is just r-foo in conda-forge.

[wolfv]

@pb01ka Isuru mentioned that the current generator only emits ${R_ARGS} whcih doesn't work on windows (needs %R_ARGS%).

[pb01ka]

Noted. This should be very small. Let me raise a quick PR addressing @isuruf's review comments on #2597. Let me add it as a TODO item. TY.

[pb01ka]

This is unnecessary. Package foo in CRAN is just r-foo in conda-forge.

I see. Since every CRAN package foo maps to r-foo on conda-forge by convention, there is no lookup table needed (unlike the PyPI case where names can differ arbitrarily).

That said, there is still a narrower question worth settling: should generate-recipe warn the user when a dependency is not yet available on conda-forge at all?

Option A - no check, rely on the solver

Keep the current behaviour. If r-foo is missing from conda-forge, the user finds out when they try to build the recipe and the solver says "package r-foo not available". Simple, no extra network call, and the error message is clear enough.

Option B - warn at generation time

After generating the recipe, check each collected dependency against conda-forge and print a warning for any that are absent. The user knows upfront which dependencies they will need to package first, without having to attempt a build.

The trade-off is: Option A is zero-cost but surfaces the problem late; Option B surfaces it early at the cost of an extra network round-trip during generate-recipe.

Which would you prefer?

Also, am I missing something? Please let me know your thoughts.

[isuruf]

In grayskull, it warns at generation time and there's an option to recursively generate all recipes needed.

[isuruf]

The ultimate goal here should be to generate a v1 recipe equivalent of https://github.com/conda-forge/r-gmp-feedstock/blob/main/recipe/meta.yaml for r-gmp. Thanks to @wolfv we are almost there, but not quite yet.

[pb01ka]

In grayskull, it warns at generation time and there's an option to recursively generate all recipes needed.

I see. So we should follow the same convention here. TYSM for your response on my question. I am already working on addressing #2563 (comment). Once I open a PR for it, then I will address the first TODO item.

Also noted, #2563 (comment)