Consider deprioritizing the environment variable provider about spin

[lann]

This sounds like the kind of small, technically-breaking-but-probably-low-impact changes that would be good for a 3.0

[kate-goldenring]

This priority of providers is not documented, so i have a PR up to at least describe the current state: fermyon/developer#1322

[itowlson]

My guess is that the thought behind the order was that a user writing SPIN_VARIABLE_DB_ADDR=foo spin up should get the behaviour they (thought they) asked for, even if another provider was in play.

[lann]

That was my intent, but in some sense environment variables are generally going to be "more static" than say vault, so it does make some sense for it to be lower priority.

[itowlson]

I don't really get the "more static" argument. To me the criterion is more like "more explicit." Although I do get that an "ambient" EV is not very explicit, and we can't tell that apart from a "provided on the line with the command" EV... And since --runtime-config-file is always explicit, any "provided on the line" EV is arguably setting itself up for ambiguity anyway!

[lann]

The "staticness" argument is just a pragmatic one: you only get to update env vars when you restart the process, but you can update e.g. vault much more frequently; it is just more useful for the more-frequently-updatable provider to have higher precedence rather than being masked by the the lass-frequently-updatable provider.