Spin Improvement Proposal: Supporting multiple build profiles #3075
Conversation
This PR adds a SIP describing changes that'd allow developers to define and use multiple build profiles for components in a `spin.toml` file Signed-off-by: Till Schneidereit <till@tillschneidereit.net>
| The application defined in this manifest can be run in various configurations: | ||
|
|
||
| - `spin up`: uses the release/default builds for everything | ||
| - `spin up --profile debug`: uses builds of the profile named `debug` of all components that have them, default builds for the rest |
There was a problem hiding this comment.
My worry here is the disconnection between the build and run steps. I know that in three months I will be tweaking an app and wondering why my changes aren't showing and it will be because I am building release and running debug or something. This was one of the concerns that stopped us doing this before (maddeningly, I can no longer find the discussion, sorry). Do you believe this is a false consideration, or do you have ways to mitigate it?
There was a problem hiding this comment.
yeah, that's a very good point. One, and perhaps the only real one, option is to make spin up imply spin build.
This is the behavior cargo run has, and it makes sense to me. Cargo of course has the benefit of having much deeper understanding of what a build implies, but maybe that's not actually key here?
There was a problem hiding this comment.
spin up isn't like cargo run though. It's more like wasmtime run. It cares only about the presence of the binary; its job is to get the binary up and running as quickly as possible.
(At least that's how it is today. We can, of course, change that; but making it default to building would be a breaking change for certain scenarios. Which is not a blocker, but we'd want to socialise it well in advance of the change.)
I'd be concerned about a philosophy of "build everywhere." Okay, I built it to make sure that it typechecked and was warning free, now let me run it, huh, looks like it built again. Push it to a registry, built again; deploy it, built again. For sure Rust components will fairly quickly (and fairly quietly) figure out that the build is a no-op. But rebuilding a single minimal JS component (with no changes) takes more than half a second on my computer, and produces 2/3 of a screen of npm spew Maybe that's an extreme case but it does give me collywobbles about defaulting to rebuilding with every single operation. I do appreciate the consistency guarantees it provides though - after all, even today we have a risk of "oops I forgot to build before pushing"!
Signed-off-by: Till Schneidereit <till@tillschneidereit.net>
|
|
||
| 1. Adding an optional `[component.name.profile.profile-name]` table to use for defining additional build profiles of a component | ||
| 2. Adding a `-profile [profile-name]` CLI flag and `SPIN_PROFILE` env var to `spin {build, watch, up}` to use specific build profiles of all components (where available, with fallback to the default otherwise) | ||
| 1. By popular demand, the `debug` profile can be selected using the `--debug` CLI flag |
There was a problem hiding this comment.
While I added the --debug flag for now, I think there might be a reason for not doing so after all: we might want to later add support for actual debugging to Spin, and would in that case probably regret having used this flag for profile selection.
There was a problem hiding this comment.
@tschneidereit Ah, yep. Reserving --debug for "I want to actually attach a debugger" is a good point. So spin up --build --debug would build the debug profile and run under the debugger; but spin up --build --profile=debug would build the debug profile but run it without actually debugging. The first case does feel it should (eventually) be the "common case" and get the fancy flag.
There was a problem hiding this comment.
Just throwing in my perspective that attaching the debugger sounds to me like the special case, and I would expect --debug to only refer to the debug profile, but that's likely due to my perspective as a Rust programmer.
|
|
||
| 1. Adding an optional `[component.name.profile.profile-name]` table to use for defining additional build profiles of a component | ||
| 2. Adding a `-profile [profile-name]` CLI flag and `SPIN_PROFILE` env var to `spin {build, watch, up}` to use specific build profiles of all components (where available, with fallback to the default otherwise) | ||
| 1. By popular demand, the `debug` profile can be selected using the `--debug` CLI flag |
There was a problem hiding this comment.
Just throwing in my perspective that attaching the debugger sounds to me like the special case, and I would expect --debug to only refer to the debug profile, but that's likely due to my perspective as a Rust programmer.
| 1. Adding an optional `[component.name.profile.profile-name]` table to use for defining additional build profiles of a component | ||
| 2. Adding a `-profile [profile-name]` CLI flag and `SPIN_PROFILE` env var to `spin {build, watch, up}` to use specific build profiles of all components (where available, with fallback to the default otherwise) | ||
| 1. By popular demand, the `debug` profile can be selected using the `--debug` CLI flag | ||
| 2. `release` is the default profile, but can also be explicitly named for regularity, including with the `--release` alias |
There was a problem hiding this comment.
Is the reason for making release the default, for backwards compatibility reasons? The Cargo model of debug being the default makes most sense to me, but I'm certainly not without bias in this regard 😄 .
There was a problem hiding this comment.
I like release being the default in part because spin build then spin registry push is a promoted flow and i like orienting around defaulting to pushing release builds
|
|
||
| A profile can be selected for the entire application in three ways: | ||
| 1. Via the `--profile=[profile-name]` CLI flag to `spin {build, up, watch}` | ||
| 2. Via the `--debug` CLI flag to `spin {build, up, watch}` as an alias for `--profile=debug` |
There was a problem hiding this comment.
You mention a --release CLI flag but not here. I'm guessing that's just an oversight?
This PR adds a SIP describing changes that'd allow developers to define and use multiple build profiles for components in a
spin.tomlfile