You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sharing Arduino IDE sketches between users is pretty handicapped right now, because the sketch.yaml project file isn't yet supported in the IDE, and there is no way to share the settings that are manually configured in the "Tools" menus. This is in spite of the fact that I've already configured the sketchbook location to the root of my GitHub repository's sandbox.
The first MVP behavior wouldn't even need to support multiple build profiles or provide any additional user interface. It could be as simple as:
If the sketch .ino has a sketch.yaml file next to it, and
if the sketch.yaml explicitly defines a default profile, then
load & save all platform properties to/from the default profile
load & save all board properties to/from the default profile's FQBN
load & save all library installations to/from the default profile
Describe the current behavior
Board Selection
When opening a sketch Arduino IDE does select the board, custom board options, and port according to the selections the user had the last time that sketch was open. However, this data is stored separately from the sketch, which causes two problems:
There is no way to share that configuration along with the sketch
If the path of the sketch is changed, the configuration data is disassociated from the sketch (the data is keyed to the sketch path)
Dependencies Management
Library and platforms can only be managed globally. There is no way to control dependencies on a per-sketch basis.
This results in the frustrating situation where a working project can be broken at any time simply by installing a library for use with another project.
The users must resort to inefficient and complex measures to control dependencies. For example, they may vendor library dependencies inside the sketch, which may require modifications to the library source code and makes updates inconvenient.
Per-sketch dependencies management is also the root motivation for the majority of the many users passionately requesting the implementation of a portable mode (#122). For most applications, use of a portable IDE installation for project dependencies management is inferior to the build profiles system, so assuming the effort for this proposal is approximately equal or lesser, the finite development resources would be more effectively investing into adding support for build profiles than to implementing portable mode.
Describe the request
Sharing Arduino IDE sketches between users is pretty handicapped right now, because the
sketch.yaml
project file isn't yet supported in the IDE, and there is no way to share the settings that are manually configured in the "Tools" menus. This is in spite of the fact that I've already configured the sketchbook location to the root of my GitHub repository's sandbox.The first MVP behavior wouldn't even need to support multiple build profiles or provide any additional user interface. It could be as simple as:
.ino
has asketch.yaml
file next to it, andsketch.yaml
explicitly defines a default profile, thenDescribe the current behavior
Board Selection
When opening a sketch Arduino IDE does select the board, custom board options, and port according to the selections the user had the last time that sketch was open. However, this data is stored separately from the sketch, which causes two problems:
Dependencies Management
Library and platforms can only be managed globally. There is no way to control dependencies on a per-sketch basis.
This results in the frustrating situation where a working project can be broken at any time simply by installing a library for use with another project.
The users must resort to inefficient and complex measures to control dependencies. For example, they may vendor library dependencies inside the sketch, which may require modifications to the library source code and makes updates inconvenient.
Per-sketch dependencies management is also the root motivation for the majority of the many users passionately requesting the implementation of a portable mode (#122). For most applications, use of a portable IDE installation for project dependencies management is inferior to the build profiles system, so assuming the effort for this proposal is approximately equal or lesser, the finite development resources would be more effectively investing into adding support for build profiles than to implementing portable mode.
Arduino IDE version
2.3.4-nightly-20241120
Operating system
All
Operating system version
Any
Additional context
Additional requests
Related
Issue checklist
The text was updated successfully, but these errors were encountered: