sway

sway copied to clipboard

If you run forc build --silent you would get see some output on your stderr, for example:

❯ forc build --silent
  Compiled library "core".
  Compiled library "std".
  Compiled contract "transaction_block_height".
  Bytecode size is 84 bytes.

There is a case of why --quiet or --silent flags exist.

quiet doesn't necessarily mean silent. For some commands, it means reduce verbosity (the opposite of -v|--verbose). For instance, mplayer has a --quiet and a --really-quiet. With some commands, you can use -qqq to decrease verbosity 3 times.

See the following for the meaning of silent vs quiet.

I'm having difficulties using forc as a library since its design seems to be geared towards it being used only as a command-line app.

Ideally, I could call

  forc_build::build(BuildCommand {
                path: Some(path),
                locked: false,
                silent_mode: true,
                ..Default::default()
            })

in my process without it spamming my stderr. Currently, my workaround is to run this in a separate process.

Although there are ways of controlling when can somebody write to stderr, they are difficult to get right in an async environment.

Regardless of my use case, forc should allow for differing levels of verbosity. Ultimately to have a super-quiet aka silent mode whose only means of communicating is via the exit code.

forc currently uses tracing for its logging implementation. The tracing subscriber we use for handling logged messages applies an environment filter which defaults to the "info" log-level.

The environment filter level can be set via the RUST_LOG env var, which you can read a little more about here. You should be able to do something like RUST_LOG=off forc build to disable all of forc's logging output altogether.

However, at present this won't stop any of the colored/formatted output or compiler output because for now, these are still written directly to stdout, bypassing the tracing logger entirely. I've opened #2374 for this, #1661 is also related.

I've opened #2375 w.r.t. setting the filter-level via CLI.

I'm having difficulties using forc as a library since its design seems to be geared towards it being used only as a command-line app.

Yes, we're still in the process of peeling out functionality from the main CLI into dedicated subcrates - we've come a long way since #863 but there's still more to do (#1950 and #885 also related).

Would you mind sharing more details about your current use-case? Depending on your use-case, you might be better off using forc-pkg directly, though there are certainly still valid motivations for using forc as a lib (e.g. sway-lsp does as currently it's the only way to get forc's current git tag for the implicit std and core dependencies).

Would you mind sharing more details about your current use-case? Depending on your use-case, you might be better off using forc-pkg directly

I'm creating a repo that will contain e2e tests that exercise forc, fuel-core, and the RS SDK.

Since I want to have git-revision-grained control over which forc I'm using, I've opted for using forc as a library.

I didn't want to have any stdout/stderr output if contracts were compiled successfully (i.e. silence is golden). But this was made difficult due to the library writing to stderr.

Temporarily intercepting this could have been achieved through something like gag, but I'm pretty sure it would fall apart when combined with asynchronousness.

After I got a panic from forc I decided to ultimately create my own forc binary that would use the library. This way I'd get process isolation, and the ability to swallow the stderr until forc could be made more silent. Not to mention the sweet work done by the forc cli :)