-
-
Notifications
You must be signed in to change notification settings - Fork 437
Added gRPC functions to manage libraries in profiles #3019
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@ ## master #3019 +/- ## ========================================== - Coverage 68.39% 67.34% -1.06% ========================================== Files 241 246 +5 Lines 22734 23137 +403 ========================================== + Hits 15550 15582 +32 - Misses 5988 6350 +362 - Partials 1196 1205 +9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
As stated by @per1234: > Build profile data is already provided via the LoadSketch method, so it > seems that even a mechanism that is truly for getting profile data should > be implemented by simply expanding the SketchProfile message to contain > all the data of the build profile (actually kind of silly that it > currently only provides a subset of the profile data). arduino#3019 (comment)
Requested change has been made. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients would love to use a dedicated message to add the latest version of the library (without listing the available versions), and maybe add the currently installed version that errors if the library is not installed.
And also corresponding messages: InitProfileRequest -> ProfileCreateRequest InitProfileResponse -> ProfileCreateResponse
The function is now split into two functions: - librariesGetAllInstalled that requires a librariesmanager.Explorer. - libraryResolveDependencies that requires only a librariesindex.Index and do not require anymore a librariesmanager.Explorer.
dbac430 to
2327b35
Compare
Hello Cristian,
Thanks for your great work 💪 I’ve been testing this area from the IDE side and was wondering how this feature is expected to work with an IDE or editor. Maybe this isn’t the most appropriate channel, but I guess you’re the best person to ask.
It’s clear there’s a real need for this feature:
- https://github.com/thelastoutpostworkshop/arduino-maker-workshop is a great example but doesn’t use gRPC
- https://github.com/devista-consulting/arduino-sketch-vault is a clever workaround for IDE 2.x but doesn’t use the CLI
While reading the PR and the related IDE issue arduino/arduino-ide#2573, I was trying to understand how profiles are meant to behave over gRPC, maybe later in Arduino IDE 2.x:
- If an IDE opens two sketches with different profiles (e.g.
arduino:avr:unoandesp32:esp32:esp32da), should each sketch have its own gRPC client or session? - When switching or activating a profile, does the CLI reinitialize the build environment (toolchains, platforms, libraries), or are these shared and cached? For example, if
libAis installed in profileA but not in profileB, will a library search over gRPC return different results for each profile? - If multiple profiles use the same library, will it be installed multiple times, or can they share a global copy? Since each sketch can have its own
sketch.yaml, does that mean the same dependency could be downloaded many times? - When using gRPC, should
compile,upload, etc. always loadfqbn,port, and other settings from the active profile, or should clients omit them?
I really like how profiles make builds reproducible and easy to share — that’s perfect for CI or collaborative work. But in an IDE that uses gRPC interactively, managing multiple isolated clients could get heavy, especially if it means repeated downloads.
In my current setup I treat sketch.yaml mostly as a lightweight config file. Libraries and platforms are managed globally, and if something is missing, the user only gets a warning instead of full profile enforcement.
I’d be curious to hear how Arduino sees this working long-term on the gRPC side — especially for IDE integration. Will profiles act more like isolated environments or just as stored build settings that can be written and updated through gRPC?
No hurry with this. Thanks a lot for your time
Please check if the PR fulfills these requirements
See how to contribute
before creating one)
our contributing guidelines
UPGRADING.mdhas been updated with a migration guide (for breaking changes)configuration.schema.jsonupdated if new parameters are added.What kind of change does this PR introduce?
This is an extract of #2917 containing only the gRPC part of the PR.
What is the current behavior?
Adds only the gRPC functions for managing libraries in profiles, no user-facing changes.
What is the new behavior?
Does this PR introduce a breaking change, and is titled accordingly?
No
Other information