Is ${VAR:-default} substitution in task YAML still wanted, given envs: already supports defaults?

[MitaliMSahoo]

Hi maintainers,

I was looking at _fill_in_env_vars in sky/task.py and noticed this commented-out line with a TODO above it:

# TODO(zongheng): support ${ENV:-default}?
...
# pattern = r'\$\{?([a-zA-Z_][a-zA-Z0-9_]*)(?::-([^}]*))?\}?'

This looks like it was exploring bash-style default-value syntax (${VAR:-default}) for env var substitution inside file_mounts, service, workdir, and volumes fields.

Before I dig into implementing it, I wanted to check: is this still desired? From what I can tell, the current docs already cover the main motivating use case, setting a default directly in envs: and letting users override it with --env:

envs:
  MODEL_SIZE: 13b   # default, overridable via --env MODEL_SIZE=70b
file_mounts:
  /checkpoint/${MODEL_SIZE}: ~/local_dir

So ${VAR:-default} would mostly be a more compact/inline alternative to that, rather than solving something uncovered. Implementing it cleanly also has a real wrinkle: _fill_in_env_vars does substitution on the whole field after json.dumps, so a default value containing }, ", or \ would need care to avoid corrupting the JSON round-trip before json.loads.

A few questions:
1. Is there still appetite for this, or has the envs:-default pattern made it redundant?
2. If it's still wanted, is inline-only support acceptable (i.e., only ${VAR:-default}, not ${VAR:-${OTHER}} recursively), or does it need to compose with the existing substitution?
3. Any specific edge cases (e.g., defaults containing special chars) you'd want covered in tests if I pick this up?

Happy to send a PR if this is still valued, just want to avoid duplicating a mechanism you've already deliberately built a different way, thanks!