Closed lihaoyi closed 1 month ago
I added a line in the changelog; we can postpone adding it to the main readme body until after it is published to avoid confusion
IMHO, we shouldn't postpone the documentation of a new feature to a subsequent release. It would be missing in the tagged release then and not available for offline reading, for example.
We could add a since <next version>
marker to the new doc section, which would be helpful in any case.
Updating it together with tagging/publishing the release would ensure the smallest gap between what's documented and what's published. I don't want people to read docs and have to consciously skip parts that dont apply
It's a compromise, but some compromise is inevitable when most people will see the docs on the web from the latest version of main
while releases are done less frequently.
It's your call.
I kind of disagree, though. It's what we did in the past and what I and others do in other projects. The Readme and other documentation should reflect the current state of the branch it belongs to. Looking at some possibly unreleased state is an inherent property of looking at the main
branch. In contrast to looking at a tag or release branch. It's a good thing to keep features and their docs close, ideally in the same PR. That enables us to cut a release including its documentation at any point in time.
Users can look at a specific tag rather easily. The docs then always reflects that version.
To provide stable documentation reflecting a specific version, we could and probably should just copy a rendered version to ghpages
. That can be automated.
Fixes https://github.com/com-lihaoyi/os-lib/issues/282
Unlike usage of
System.in
/System.out
/System.err
programmatically, or thescala.Console
equivalents, output from subprocesses withos.Inherit
is not affected bySystem.setIn
/setOut
/setErr
. This is often counterintuitive, because you expect redirecting these streams to redirect all output, only to find output from subprocess leaking through a side channel to the original processin
/out
/err
.This PR adds the
os.Inherit.in
/out
/err
dynamic variables, which can be used to re-assignos.Inherit
on a scoped threadlocal basis. This allows developers who useSystem.setOut
orConsole.withOut
to also redirect subprocess output within the scope of the stdout redirect, without users working within those scopes to have to remember to redirect them manually at every callsite.Because we do not control
System.setOut
orConsole.withOut
, there isn't really a way for us to detect and do this automatically (e.g. redirects may happen even before OS-Lib has been even classloaded) and so we have to rely on it being opt-in.As an escape hatch, in case users do not want this behavior, we provide a
os.Inherit0
redirect which performs identically to the originalos.Inherit
even in the process of redirectingos.Inherit.{in,out,err}
Covered by an added unit test