Added gRPC functions to manage libraries in profiles #3019
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)
| // Name of the library. | ||
| string name = 1; | ||
| // Version of the library if taken from the Library Index. | ||
| string version = 2; |
There was a problem hiding this comment.
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:
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:
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 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 |
|
Hi @dankeboy36! Thank you for your valuable feedback, as always.
The basic idea is that when a profile is in use, the platforms and libraries installed globally should have no effect, and only the platforms and libraries listed in the profile should be visible. This idea was implemented by adding the message InitRequest {
// An Arduino Core instance.
Instance instance = 1;
// Profile to use.
string profile = 2;
// The path where the sketch is stored.
string sketch_path = 3;
}An instance initialized with a profile should be able to see only the libraries listed in the profile, and I've actually checked that this is the case, using the following profile: If I try to initialize an instance of the CLI with the profile and try to get the list of installed libraries: err := srv.Init(&rpc.InitRequest{
Instance: inst,
SketchPath: sketchPath.String(),
Profile: "uno",
}, stream)
res, err := srv.LibraryList(ctx, &rpc.LibraryListRequest{
Instance: inst,
All: true,
})
require.NoError(t, err)
for _, lib := range res.InstalledLibraries {
fmt.Println("LIB>",
lib.GetLibrary().GetName(),
lib.GetLibrary().GetVersion(),
lib.GetLibrary().GetLocation(),
lib.GetLibrary().GetInstallDir())
}I got the expected: The Servo library is listed as So, based on the previous test, the answer to the following question is:
Yes, the result will differ depending on the profile. By the way, there is a distinction between a library search (i.e., searching for a library in the Library Index) and listing installed libraries. In the first case, searching for a library will always produce the same result regardless of the selected profile; however, listing the installed libraries will show different results based on the selected profile.
Libraries and platforms installed through profiles are placed in a private folder inside
The
The above must surely be fixed in the next releases. I'll open an issue for that. |
|
We are currently using this API in the AppLab IDE to manage profiles in the sketch. This is still experimental, and your suggestions and thoughts are more than welcome. Thanks for taking the time to write them down. 🙏🏼
At the moment, I would say that they serve both purposes:
The hard question is how all of this integrates with the IDE? My envisioned gRPC API involves the IDE creating multiple instances (using the Currently, I understand the Arduino IDE 2 uses a global instance (without a profile) that might be shared across all sketches that do not use profiles. I see that this could complicate things when the profiles are introduced because each UX business logic needs to be implemented twice, once for the classic "non-profiled" sketches and once for "profiled" sketches. There are still changes to the API to be made to make it IDE-friendly. The current state of the gRPC API is still not ready for that, but the above is the direction I'd like to see in the future. |
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