Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix makers formatting #535

Merged
merged 3 commits into from
Mar 29, 2021

Conversation

MartinKavik
Copy link
Contributor

Fixes #533

There are two commits, the first fixes the issue, the second one fixes cargo make ci-flow on Windows.

The reason why formatting works when you run makers indirectly (through cargo run or cargo make) is that cargo use a special print function: https://github.com/rust-lang/cargo/blob/e4aebf0a039ca3787f3ce98a9d469a3187f83706/src/cargo/core/shell.rs#L327-L340 with Windows-only code. Note: There are multiple Unix/Windows "hacks" in the linked file to make the shell work as expected.

Another way is to enable ANSI support globally, just like Trunk or other apps do it. This approach has been used in this PR. We need to call a native API to enable it: https://github.com/ogham/rust-ansi-term/blob/ff7eba98d55ad609c7fcc8c7bb0859b37c7545cc/src/windows.rs

src/lib/mod.rs Outdated
@@ -195,5 +195,9 @@ mod version;

/// Handles the command line arguments and executes the runner.
pub fn run_cli(command_name: String, sub_command: bool) {
#[cfg(windows)]
if let Err(err) = ansi_term::enable_ansi_support() {
eprintln!("error enabling ANSI support: {:?}", err);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure we need to print it to the users.... if it doesnt work, no big deal i guess. wdyt?
also, why not do it in makers.rs? since cargo is already fixing it for us, we can just push the fix to the makers executable only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote it in makers.rs first but then I've moved it to CLI to satisfy linters (otherwise it breaks the rule not used crate ansi_term or something like that).
I've added eprintln for easier user reporting when it fails.

So
I'll move it back to makers.rs and satisfy/disable the linter rule for it somehow.
Should I remove that eprintln call?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wonder how to silence that linter for specific case, so in future i don't forget some crates in...
maybe than, just add some bool from makers/main -> cli that tell it if to use it or not... crappy hack.

eprintln -> ya, lets remove it. i'm not sure users would find that helpful and many people already complain that cargo make prints out too much stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code updated in the latest commit.

From https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unused-crate-dependencies:

This lint is "allow" by default because it can provide false positives depending on how the build system is configured. For example, when using Cargo, a "package" consists of multiple crates (such as a library and a binary), but the dependencies are defined for the package as a whole. If there is a dependency that is only used in the binary, but not the library, then the lint will be incorrectly issued in the library.

@sagiegurari
Copy link
Owner

@MartinKavik thanks a lot!!!
few questions:

second one fixes cargo make ci-flow on Windows.

what does this mean? i'm running ci flow on windows today, so what was i missing?
why do we need all those removals of './'?
(again, i don't have windows, so i only look at the github windows execution which seems ok.

For Windows users: You need to allow to run PowerShell scripts

can you explain this one? why do we need powershell for cargo make? i usually default to cmd.

@MartinKavik
Copy link
Contributor Author

what does this mean? i'm running ci flow on windows today, so what was i missing?
why do we need all those removals of './'?

image

It's pretty "standard error" for many tools on Windows. The first related issue I was able to find: rust-lang/rustfmt#1873. It happens at least in Git Bash and PowerShell. Maybe it will be fixed in the next rustfmt version or it already works in nightly or there are other factors, who knows :) I would be probably able to track the real problem, but I don't want to kill time unless necessary.


can you explain this one? why do we need powershell for cargo make? i usually default to cmd.

ci-flow with the default PowerShell settings:

image

One test:

image

You can switch between cmd and poweshell multiple ways and a Windows update has changed the default shell to PS. I don't know which settings affect the cargo-make scripts but probably there is a way.

@codecov-io
Copy link

Codecov Report

Merging #535 (901cc3d) into master (ccce394) will decrease coverage by 27.59%.
The diff coverage is n/a.

❗ Current head 901cc3d differs from pull request most recent head 419f3c5. Consider uploading reports for the commit 419f3c5 to get more accurate results
Impacted file tree graph

@@             Coverage Diff             @@
##           master     #535       +/-   ##
===========================================
- Coverage   92.92%   65.33%   -27.60%     
===========================================
  Files          98       98               
  Lines       18672    18672               
===========================================
- Hits        17351    12199     -5152     
- Misses       1321     6473     +5152     
Impacted Files Coverage Δ
src/lib/cache.rs 58.46% <ø> (ø)
src/lib/cli.rs 36.16% <ø> (-53.58%) ⬇️
src/lib/cli_commands/diff_steps.rs 100.00% <ø> (ø)
src/lib/cli_commands/list_steps.rs 94.02% <ø> (-2.99%) ⬇️
src/lib/cli_commands/print_steps.rs 83.33% <ø> (ø)
src/lib/command.rs 92.92% <ø> (-0.89%) ⬇️
src/lib/condition.rs 90.61% <ø> (-7.05%) ⬇️
src/lib/config.rs 75.86% <ø> (ø)
src/lib/descriptor/cargo_alias.rs 88.23% <ø> (ø)
src/lib/descriptor/descriptor_deserializer.rs 63.88% <ø> (ø)
... and 83 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ccce394...419f3c5. Read the comment docs.

@@ -21,6 +21,8 @@ fn get_name() -> String {
}

fn main() {
#[cfg(windows)]
let _ = ansi_term::enable_ansi_support();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question, do we need the let _ here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternative would be something like:

#[allow(unused_must_use)]
{
      #[cfg(windows)]
      ansi_term::enable_ansi_support();
}

I didn't test it but I've found this workaround on stackoverflow or a Rust forum / issue.

This doesn't work for some reasons:

#[allow(unused_must_use)]
#[cfg(windows)]
ansi_term::enable_ansi_support();

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets leave it. thanks for the explanation.

@sagiegurari
Copy link
Owner

@MartinKavik thanks a lot for the answers :)

  • ./ issue - feels like rustfmt issue. strange one by the way. but thanks for explaining and let's keep your fix.
  • powershell - forgot about that test. i usually run that in CI which has powershell scripting enabled, so never saw it.
    I'll probably extend your comment in the contribution doc a bit.

Will probably merge it later today/tomorrow.
I'll first create a new dev branch for it.

@sagiegurari sagiegurari self-assigned this Mar 29, 2021
@sagiegurari sagiegurari added this to the 0.32.15 milestone Mar 29, 2021
@sagiegurari sagiegurari changed the base branch from master to 0.32.15 March 29, 2021 16:35
@sagiegurari
Copy link
Owner

Ran few manual tests on linux. looks awesome. thanks again @MartinKavik
you can now update the second PR so i can merge it as well (i tested it also).

@sagiegurari sagiegurari merged commit d2ba928 into sagiegurari:0.32.15 Mar 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Broken makers output formatting in terminal (Windows)
3 participants