fix(test): Expose '--no-capture' in favor of --nocapture by epage · Pull Request #139224 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
Comment on lines +202 to +204
Area: `#[test]` / the `test` library
Relevant to the library API team, which will review and decide on the PR/issue.
labels
Area: The compiletest test runner
Area: The testsuite used to check the correctness of rustc
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
labels
fix(test): Expose '--no-capture', deprecating '--nocapture' fix(test): Expose '--no-capture' in favor of --nocapture
Nominated for discussion during a libs-api team meeting.
and removed T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
labels
This will help with hiding some options in --help
This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).
An alternative could have been to take a value, like --capture <value> (e.g. pytest does this).
Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283).
Most of pytests modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
By deprecating --nocapture, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in rust-lang#134283
I'm punting for now on the naming of RUST_TEST_NOCAPTURE.
I feel like T-testing-devex should do a wider look at environment
variables role in libtest before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
- Deprecate in favor of
RUST_TEST_NO_CAPTURE - Deprecate in favor of
RUST_TEST_CAPTURE
Other CLI flags were evaluated for casing consistency:
--logfilehas the same problem but was deprecated in rust-lang#134283
Fixes rust-lang#133073
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request
fix(test): Expose '--no-capture' in favor of --nocapture
This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).
An alternative could have been to take a value, like --capture <value> (e.g. pytest does this).
Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283).
Most of pytests modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed.
By deprecating --nocapture, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in rust-lang#134283
I'm punting for now on the naming of RUST_TEST_NOCAPTURE.
I feel like T-testing-devex should do a wider look at environment
variables role in libtest before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
- Deprecate in favor of
RUST_TEST_NO_CAPTURE - Deprecate in favor of
RUST_TEST_CAPTURE
Other CLI flags were evaluated for casing consistency:
--logfilehas the same problem but was deprecated in rust-lang#134283
Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.
Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809
T-testing-devex FCP: rust-lang#133073 (comment)
Fixes rust-lang#133073
bors added a commit to rust-lang-ci/rust that referenced this pull request
ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request
fix(test): Expose '--no-capture' in favor of --nocapture
This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).
An alternative could have been to take a value, like --capture <value> (e.g. pytest does this).
Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283).
Most of pytests modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed.
By deprecating --nocapture, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in rust-lang#134283
I'm punting for now on the naming of RUST_TEST_NOCAPTURE.
I feel like T-testing-devex should do a wider look at environment
variables role in libtest before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
- Deprecate in favor of
RUST_TEST_NO_CAPTURE - Deprecate in favor of
RUST_TEST_CAPTURE
Other CLI flags were evaluated for casing consistency:
--logfilehas the same problem but was deprecated in rust-lang#134283
Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.
Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809
T-testing-devex FCP: rust-lang#133073 (comment)
Fixes rust-lang#133073
bors added a commit to rust-lang-ci/rust that referenced this pull request
bors added a commit to rust-lang-ci/rust that referenced this pull request
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#139224 - epage:nocapture, r=thomcc
fix(test): Expose '--no-capture' in favor of --nocapture
This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).
An alternative could have been to take a value, like --capture <value> (e.g. pytest does this).
Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283).
Most of pytests modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed.
By deprecating --nocapture, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in rust-lang#134283
I'm punting for now on the naming of RUST_TEST_NOCAPTURE.
I feel like T-testing-devex should do a wider look at environment
variables role in libtest before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
- Deprecate in favor of
RUST_TEST_NO_CAPTURE - Deprecate in favor of
RUST_TEST_CAPTURE
Other CLI flags were evaluated for casing consistency:
--logfilehas the same problem but was deprecated in rust-lang#134283
Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.
Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809
T-testing-devex FCP: rust-lang#133073 (comment)
Fixes rust-lang#133073