Codecov Report

❌ Patch coverage is55.74230% with158 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.17%. Comparing base (8f81c72) to head (8b4b3a5).

@@            Coverage Diff             @@##           master    #3019      +/-   ##==========================================- Coverage   69.42%   69.17%   -0.26%==========================================  Files         242      247       +5       Lines       18632    18935     +303     ==========================================+ Hits        12936    13099     +163- Misses       4502     4604     +102- Partials     1194     1232      +38

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

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 issuearduino/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:uno andesp32: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, iflibA is 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 ownsketch.yaml, does that mean the same dependency could be downloaded many times?
• When using gRPC, shouldcompile,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 treatsketch.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

Hi@dankeboy36!

Thank you for your valuable feedback, as always.

If an IDE opens two sketches with different profiles (e.g. arduino:avr:uno and esp32:esp32:esp32da), should each sketch have its own gRPC client or session?

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 theprofile parameter in theInit method:

messageInitRequest {// An Arduino Core instance.Instanceinstance=1;// Profile to use.stringprofile=2;// The path where the sketch is stored.stringsketch_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:

profiles:  uno:    fqbn: arduino:avr:uno    platforms:      - platform: arduino:avr (1.8.3)    libraries:      - Servo (1.1.6)

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:=rangeres.InstalledLibraries {fmt.Println("LIB>",lib.GetLibrary().GetName(),lib.GetLibrary().GetVersion(),lib.GetLibrary().GetLocation(),lib.GetLibrary().GetInstallDir())}

I got the expected:

LIB> Servo 1.1.6 LIBRARY_LOCATION_PROFILE /home/cmaglie/.arduino15/internal/Servo_1.1.6_663e17729cbd9f93/ServoLIB> Wire 1.0 LIBRARY_LOCATION_PLATFORM_BUILTIN /home/cmaglie/.arduino15/internal/arduino_avr_1.8.3_40b0bc3206d75f60/libraries/WireLIB> EEPROM 2.0 LIBRARY_LOCATION_PLATFORM_BUILTIN /home/cmaglie/.arduino15/internal/arduino_avr_1.8.3_40b0bc3206d75f60/libraries/EEPROMLIB> HID 1.0 LIBRARY_LOCATION_PLATFORM_BUILTIN /home/cmaglie/.arduino15/internal/arduino_avr_1.8.3_40b0bc3206d75f60/libraries/HIDLIB> SPI 1.0 LIBRARY_LOCATION_PLATFORM_BUILTIN /home/cmaglie/.arduino15/internal/arduino_avr_1.8.3_40b0bc3206d75f60/libraries/SPILIB> SoftwareSerial 1.0 LIBRARY_LOCATION_PLATFORM_BUILTIN /home/cmaglie/.arduino15/internal/arduino_avr_1.8.3_40b0bc3206d75f60/libraries/SoftwareSerial

The Servo library is listed asLOCATION_PROFILE, the other libraries arePLATFORM_BUILTIN.

So, based on the previous test, the answer to the following question is:

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 libA is installed in profileA but not in profileB, will a library search over gRPC return different results for each profile?

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.

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?

Libraries and platforms installed through profiles are placed in a private folder inside$DATA_DIR/internal/. The same package will not be downloaded twice; there are no duplicates here. Those directories should be read-only. By the way, there are no protections in place to prevent users from making changes.

$ ls ~/.arduino15/internal/ -ltotale 200drwxr-xr-x  3 cmaglie cmaglie 4096 ott  3  2024  Adafruit_BusIO_1.16.1_ba866f2a3757c639drwxr-xr-x  4 cmaglie cmaglie 4096 ott  9  2024 'Adafruit SleepyDog Library@1.6.5_a3c453d34b90db4b'drwxrwxr-x  3 cmaglie cmaglie 4096 mag 30 16:02  arduino_arduinoOTA_1.2.1_c939277d7d79c18ddrwxr-xr-x  3 cmaglie cmaglie 4096 gen 23  2024  arduino_arduinoOTA_1.3.0_8902221f9b4869cedrwxr-xr-x  6 cmaglie cmaglie 4096 mag 30 16:02  arduino_arm-none-eabi-gcc_7-2017q4_7b7be9f526b2cb64drwxr-xr-x  8 cmaglie cmaglie 4096 nov 17 11:55  arduino_avr_1.8.3_40b0bc3206d75f60drwxr-xr-x  8 cmaglie cmaglie 4096 gen 23  2024  arduino_avr_1.8.4_7ad8ae8e9f6a9dc9drwxr-xr-x  9 cmaglie cmaglie 4096 gen 23  2024  arduino_avr_1.8.5_70334d3546efee53drwxr-xr-x  9 cmaglie cmaglie 4096 lug  1  2024  arduino_avr_1.8.6_78e0815c6047bc54drwxr-xr-x  4 cmaglie cmaglie 4096 gen 23  2024  arduino_avrdude_6.3.0-arduino17_b00caa3114ef923ddrwxr-xr-x  7 cmaglie cmaglie 4096 mag 30 16:03  arduino_avrdude_6.3.0-arduino9_734fb0aeab0d748fdrwxr-xr-x  8 cmaglie cmaglie 4096 gen 23  2024  arduino_avr-gcc_7.3.0-atmel3.6.1-arduino7_fc423089e09cfcabdrwxr-xr-x  3 cmaglie cmaglie 4096 lug  7 17:10  ArduinoBearSSL_1.7.6_3fd6f33f302ce290

When using gRPC, should compile, upload, etc. always load fqbn, port, and other settings from the active profile, or should clients omit them?

TheCompile andUpload commandsshould retrieve the FQBN and Port from the profile, and the gRPC API allows overriding them if the FQBN and Port parameters are filled. At least, that was the intention.
I put the above statement to the test, and I discovered that:

• Compile always requires the sketch path (even if it was already specified in theInit call)
• Upload always requires the sketch path (even if it was already specified in theInit call)
• Upload always requires the port address (even if it was present in the profile)
  The CLI UI actually covers this behaviour by filling in the missing pieces in the gRPC calls.

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. 🙏🏼

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?

At the moment, I would say that they serve both purposes:

• They provide isolated environments, even reproducible builds if all the versions and URLs are correctly specified.
• In a certain sense, they store the build settings, too? (having all the resources needed to build a sketch).

The hard question is how all of this integrates with the IDE?

My envisioned gRPC API involves the IDE creating multiple instances (using theCreate gRPC call), one for each open "sketch." Each instance should then be initialized (with theInit method), optionally with a profile, while the CLI manages the resources (possibly reusing/sharing to avoid wasting resources).
If the user selects a different profile, the instance should be re-initialized.

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.

I've removed the Git portion from this PR#3028 because it needs more work. It will be merged and discussed separately.