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

Printing to stdout #692

Open
cnpryer opened this issue Jul 16, 2023 · 6 comments
Open

Printing to stdout #692

cnpryer opened this issue Jul 16, 2023 · 6 comments
Labels
good first issue Good for newcomers
Milestone

Comments

@cnpryer
Copy link
Owner

cnpryer commented Jul 16, 2023

Currently most of huak operations print to stderr. An example of a command that should probably print to stdout would be huak version.

@cnpryer cnpryer added the good first issue Good for newcomers label Jul 16, 2023
@ethanbarry
Copy link

I'd be willing to try helping, but I see on line 116 of huak_python.../src/sys.rs that this is intentional.

/// NOTE: Messages are printed to stderr. This is behavior cargo implements as well to
    /// avoid polluting stdout for end users. See <https://github.com/rust-lang/cargo/issues/1473>.
    fn print(
        &mut self,
        status: &dyn Display,
        message: Option<&dyn Display>,
        color: Color,
        justified: bool,
    ) -> HuakResult<()> {
        match self.options.verbosity {
            Verbosity::Quiet => Ok(()),
            _ => self
                .output
                .message_stderr(status, message, color, justified),
        }
    }

I hope someone will let me know if this is something I could potentially help change. Thank you in advance!

@cnpryer
Copy link
Owner Author

cnpryer commented Oct 9, 2023

Hi! huak version would make sense in stdout. I'm sure there are others, but that's definitely one. The idea is that huak version is often the type of command to be used to capture versions of projects.

@ethanbarry
Copy link

Awesome! I'll see what I can do this week. Thank you!

@cnpryer
Copy link
Owner Author

cnpryer commented Oct 11, 2023

Hey just a heads up I'm planning to refactor quite a bit in order to make some of the stuff I want to work on easier to do. So it might be better to hold off until that refactor work is done.

@ethanbarry
Copy link

Great, will do. I noticed a lot changed when I debased my local copy today...

@cnpryer
Copy link
Owner Author

cnpryer commented Oct 14, 2023

I'll be working on #718. There's more to refactor, but I probably won't refactor until I've implemented that. I'm treating it as a separate binary for now, then I'll refactor shared components out after it's done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants