Revise OS-Lib mission statement

[lefou]

It currently says:

os-lib/Readme.adoc

Lines 50 to 56 in 40bc124

	OS-Lib aims to be a complete replacement for the
	`java.nio.file.Files`/`java.nio.file.Paths`, `java.lang.ProcessBuilder`
	`scala.io` and `scala.sys` APIs. You should not need to drop down to underlying
	Java APIs, as OS-Lib exposes all relevant capabilities in an intuitive and
	performant way. OS-Lib has no dependencies and is unopinionated: it exposes the
	underlying APIs in a concise but straightforward way, without introducing it's
	own idiosyncrasies, quirks, or clever DSLs.

But there are issue(s) indicating we lack some replacements of for the scala.io API.

• Read from console / standard input #335

Those issue(s) got closed without further comment or advise. Being a maintainer of os-lib for a long time if find it rather unsatisfying to close valid issues without further comments.

We should either find a good answer or revise our mission statement, that we don't aim any longer for a full replacement of the scala.io API.

[lihaoyi]

Apologies for not giving more detail in the original ticket, I should have written an explanation

I think the reasons I don't want to include stdin support as part of OS-Lib are as follows:

• How rarely it is used. Beyond beginner programs at the command line, most people writing backend services or other large JVM applications aren't going to be using stdin at all, in contrast to stdout/stderr which is used extensively for logging. This was also discussed in some detail on the contributors mailing list https://contributors.scala-lang.org/t/making-io-stdin-readline-imported-by-default/6803

• How difficult it is to provide proper support for CLI programs who need it: do we need to implement readline like Ammonite does? or use Jline? Most CLI programs that take input from the user need more than just line-buffered reading of stdin

• OS-Lib doesn't provide special support for other streams either. There is no OS-Lib method for printing to stdout or stderr.

Overall, the definition of "a complete replacement" is somewhat arbitrary. e.g. OS-Lib does not have wrappers for scala.sys.props or System.out or java.io.OutputStream. It certainly could wrap them, but in terms of ROI I judged it not worth the benefit for now. Perhaps if there's some inspired abstraction we could include it in the library, but I don't think it's an issue we should track in our issue tracker