Improve Task.{Source,Sources} API

[lefou]

Accept the following types (which are all sub-types of os.FilePath):

• os.SubPath - an sub-path resolved against moduleDir
• os.RelPath - an relative path resolved against moduleDir
• os.Path - an absolute path

We also want to accept well-formatted Stringly-typed paths, by the use of the macro-based implicit conversion from os-lib. To make that work, we need to explicitly accept the os.SubPath type. Thus we end up with a os.SubPath | os.FilePath signature, which can be a bit confusing, but gives us compile-time validation instead of potential runtime errors when paths are given as String.

[lihaoyi]

This big union type looks pretty out of place. Could we use os.FilePath here? Maybe if we add a few more implicits upstream in OS-Lib to make the conversions from string work?

[lefou]

Yeah. Once we use just os.FilePath, we can't profit from String to os.SubPath translation. We either want to support a more generic conversion for String to os.FilePath, which also means we want to handle absolute and relative paths, or find some other way to support conversion.

I committed some compromise acepting os.SubPath | os.FilePath to see if CI likes it.

[lihaoyi]

Isn't os.SubPath | os.FilePath just os.FilePath, since os.SubPath is a subclass of it?

[lefou]

@lihaoyi

Isn't os.SubPath | os.FilePath just os.FilePath, since os.SubPath is a subclass of it?

Yeah. Here's my comment from commit 5a28bbb

By using os.SubPath | os.FilePath, which is redundant as os.SubPath is already a sub-type of os.FilePath, we allow implicit converstions from String to os.SubPath.

Also from #5245 (comment)

Once we use just os.FilePath, we can't profit from String to os.SubPath translation. We either want to support a more generic conversion for String to os.FilePath, which also means we want to handle absolute and relative paths, or find some other way to support conversion.

I committed some compromise acepting os.SubPath | os.FilePath to see if CI likes it.

[lihaoyi]

Looks good to me!