docs(arduino-api): record platform_packages override scope decision (#666)#877
Conversation
…666) #666 was the open audit task asking whether `arduino_api.rs` honors `platform_packages`. Per the audit reviewer's call (matches the spirit of #664/#681 — the original LPC8xx-driven bisection workflow targeted the framework, not the API header layer): wiring an override here doesn't pay off, for three reasons documented inline. The three reasons (also in the module docstring): 1. Bisection workflows target frameworks, not the API header layer. 2. `arduino_api` is a one-shot fetcher with no `PackageBase`; threading an override would require either a `PackageBase` refactor (large change for negligible gain) or threading an `Option<PackageOverride>` through every consumer (`AvrFramework`, `ArduinoMbedCore`, `SilabsCores`). 3. PIO's atmelavr / arduino-mbed / silabs packages don't expose an `arduino-api` override key — there's no canonical PIO package name consumers can set in `platform_packages`. If a future workflow ever needs to swap the ArduinoCore-API tag per-build, the doc points future engineers at the right migration path (convert to `PackageBase`). Closes #666
|
Warning Review limit reached
Next review available in: 31 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Resolves #666 — the open audit task asking whether
arduino_api.rshonorsplatform_packages.Per the audit reviewer's call: wiring an override here doesn't pay off. ArduinoCore-API is a small, header-only library on a stable tag (
v1.5.2) that almost never changes; the bisection workflows that motivated #664 (FastLED/FastLED#3325) target framework commits, not the API header layer;arduino_apiis a one-shot fetcher with noPackageBase(unlike every other framework package in the audit), so override-wiring would require either aPackageBaserefactor or threadingOption<PackageOverride>through every consumer (AvrFramework,ArduinoMbedCore,SilabsCores); and PIO doesn't expose anarduino-apioverride key in any of the affected platforms — there's no canonical PIO name consumers can set.This PR is a docstring addition only — records the decision and points future engineers at the right migration path (convert to
PackageBasemirroringarduino_core_lpc8xx.rs) if a future workflow ever needs override capability.Closes #666
🤖 Generated with Claude Code