feat: warn about R dependencies missing from conda-forge in generated recipes

[pb01ka]

Refer #2563

⚠️ Breaking: generate-recipe cran --tree now recurses only into dependencies missing from conda-forge by default, instead of the whole dependency tree. Pass the new --full flag alongside --tree to restore the old behavior.

Summary

cran.rs already collected an R package's dependencies into a remaining_deps set while generating a recipe, but the set was discarded after use - there was no signal to the user about which of those dependencies weren't yet packaged on conda-forge. The recipe would only fail much later, at solve time, with no clear diagnostic pointing back to the missing R package.

This PR checks each collected dependency against conda-forge right after the recipe is generated, and logs a warning for any that are missing. The check goes through rattler_repodata_gateway's Gateway, with every dependency batched into a single query rather than one request per package. This mirrors the existing behavior discussed for pypi.rs, minus the name-mapping step: CRAN package foo always maps to conda-forge r-foo by convention, so no lookup table is needed.

Important Points

• Wired warn_about_missing_conda_forge_deps into generate_r_recipe, run once per generated recipe.
• Network errors are treated as "exists" (fail open) so a flaky connection doesn't block recipe generation or spam false warnings.
• Added unit tests, including a deterministic one for the network-failure branch (using the RFC 2606 .invalid TLD, which is guaranteed never to resolve).
• Changed --tree's behavior: it now recurses only into dependencies missing from conda-forge by default (matching grayskull's --recursive), instead of blindly recursing into the whole dependency tree. (refer feat: warn about R dependencies missing from conda-forge in generated recipes #2622 (comment)) Generating boilerplate recipes for packages already available on conda-forge isn't useful, since they'd need further changes to be valid anyway.
• Added a --full/-f modifier to restore the old behavior when it's genuinely wanted (e.g. building a self-contained "forge" channel that doesn't want to depend on conda-forge for anything in the tree): --tree --full recurses into every dependency regardless of conda-forge status. Has no effect without --tree.
• This started out as a separate opt-in --recursive flag alongside the untouched --tree, but feat: warn about R dependencies missing from conda-forge in generated recipes #2622 (comment) and feat: warn about R dependencies missing from conda-forge in generated recipes #2622 (comment) pointed out the two were confusingly similar at a glance, so --recursive was folded into --tree (with --full as the escape hatch) instead of shipping both.

[pb01ka]

This PR is ready for review. @wolfv Please feel free to take a look.

@isuruf You might be interested as well.

TY.

[isuruf]

Should we also recurse specifically for the dependencies this PR flags as missing from conda-forge?

Yes, but not by default.

[pb01ka]

Noted. Will update this PR tomorrow using my best judgement.

[pb01ka]

Yes, but not by default.

Addressed using my best possible judgement. I have added a --recursive flag along side --tree flag. Once my changes are reviewed, I would like some thoughts on the following question I have in my mind.

Question: should --recursive just be folded into --tree?

Now that both flags exist side by side, I want to sanity-check the design. At a high level --recursive and --tree look very similar - both walk the dependency graph and generate recipes for what they find. The only real difference is which dependencies they recurse into:

• --tree recurses into every dependency (am I right?), regardless of whether it's already on conda-forge.
• --recursive recurses only into the dependencies that are missing from conda-forge.

Given how close they are on the surface, would you prefer we:

1. Keep them as two separate flags (current state), or
2. Merge them into one - e.g. drop --recursive and instead have --tree skip dependencies already available on conda-forge (or add a modifier to --tree that toggles that behavior)?

I'm happy either way; just want to avoid shipping two options that most users will find hard to tell apart (including me 😆).

[jsmolic]

* `--tree` recurses into **every** dependency (**am I right?**), regardless of whether it's already on conda-forge.

I dont see this option in grayskull or conda-skeleton, only --recursive.

2. Merge them into one - e.g. drop `--recursive` and instead have `--tree` skip dependencies already available on conda-forge (or add a modifier to `--tree` that toggles that behavior)?

I think this makes most sense, having generated recipes for already available packages doesn't seem useful (especially given that boilerplate recipes may need further changes to be valid)

[pb01ka]

@jsmolic I used my best possible judgement to implement your suggestion,

• --tree now by default recurses only into the dependencies that are missing from conda-forge.
• --tree --full recurses into every dependency, regardless of whether it's already on conda-forge. (the older default behaviour of --tree)

The PR description is also updated to reflect the same. TY.

Please let me know if anything else needs to be done.

[pb01ka]

@wolfv Kindly take a look. This PR is passing the tests and waiting for reviews/decision. TY.

[wolfv]

I think we should use the Repodata Gateway here and query conda-forge that way. Is it possible for you to try that?

[pb01ka]

I implemented the repodata gateway approach using my best judgement. Please take a look and let me know your feedback. TY.

[wolfv]

Looks good except that one comment!

[pb01ka]

@wolfv I addressed your comment to the best of my abilities and understanding. The tests are also passing. Please take a look. TY.