[BACKPORT] Allow Task.Source
/Task.Sources
to be constructed directly from subpath string literals
#4487
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First step in #4447, by providing an alternative to the previous
os.Path
APIs.Effectively this allows us to replace
with
Pulls in com-lihaoyi/os-lib#353 from upstream to make constructing
os.SubPath
s more ergonomic by eliding the leados.sub /
prefix in the case of literal strings while still maintaining a degree of safety:..
s and absolute paths starting with/
are rejected at compile timeos.SubPath
For now we provide this as an alternative to passing in an absolute
os.Path
, but probably 99% of scenarios should be using this sub-path API rather than absolute paths since (a) it's more concise and (b) your sources should be within yourmillSourcePath
anyway. I'm not sure we can get rid of theos.Path
-taking API entirely, but we can definitely de-prioritize it and call itSourcesUnsafe
or something so that anyone who needs it can use it but most people won't use it accidentally