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

Add Target::Pipe #195

Closed
wants to merge 11 commits into from
Closed

Conversation

TilCreator
Copy link
Contributor

Now logs can be written to custom pipes and not just to stdout or stderr.

This is my take on #178.

I would be very happy to hear some feedback, since I'm quite unsure about a few changes:

  • The example seams overly complicated, mostly because I didn't want an example to write to a file. Maybe there is a better candidate than std::sync::mpsc used as a pipe for that?
  • Builder::target_pipe is my idea for not breaking too much, but maybe there is a solution to implement that into Builder::target directly?
  • In Buffer it is assumed that if target_pipe is Some, test_target is always None. Is there a better way to enforce that?

@TilCreator
Copy link
Contributor Author

I can't reproduce the failed check locally and I also didn't change anything on the code that is failing. Plz help?

@jplatte
Copy link
Contributor

jplatte commented Feb 25, 2021

It's cargo clippy, not cargo check, that's failing (and with a nightly version of clippy). I've pushed a commit to master that fixes that lint plus one more, rebasing should get rid of the CI failure now.

@TilCreator
Copy link
Contributor Author

Ah, I wasn't using the nightly version of clippy. I rebased master and the checks succeed now. thx

src/fmt/writer/mod.rs Outdated Show resolved Hide resolved
@jplatte
Copy link
Contributor

jplatte commented Feb 25, 2021

You did the rebase the wrong way around (you should rebase your branch on top of master, not the other way around).

Builder::target_pipe is my idea for not breaking too much, but maybe there is a solution to implement that into Builder::target directly?

What do you mean by "not breaking too much"? The derived traits for Target? I think I'd rather see those removed than there being a separate target_pipe builder method / field. I wonder why e.g. Hash is implemented for that in the first place.

@jplatte
Copy link
Contributor

jplatte commented Feb 25, 2021

By the way, thank you for working on this!

@TilCreator
Copy link
Contributor Author

Ups, I knew there was something wrong after at least the 5th git command, is it still worth trying to fix? ^^

@jplatte
Copy link
Contributor

jplatte commented Feb 25, 2021

It should be as easy as

// if you haven't set up the remote yet, though I guess you have
git remote add upstream https://github.com/env-logger-rs/env_logger
git fetch upstream
// rebase your branch on top of upstream's master branch
git rebase upstream/master

even now. (git should detect the duplicate commit on your branch and get rid of it)

Followed by git push --force (--force to tell git you are sure you want to rewrite the history of the remote branch).

TilCreator and others added 4 commits February 25, 2021 22:07
Now logs can be written to custom pipes and not just to stdout or stderr
Co-authored-by: Jonas Platte <[email protected]>
@TilCreator
Copy link
Contributor Author

TilCreator commented Feb 26, 2021

I have tried myself on keeping the pipe in the Target::Pipe, but that is just such a mess, so many Arc<Mutex<...>>....
Target also gets used a lot after build() to check if stdout or stdout is used, so removing or "circumenting" the derived traits of Target is hard. (The Builder is also not consumed on build().)

I will try something that takes the value out of Target::Pipe on target() or build() tomorrow.
Maybe I can even come up something better than enum Target {..., Pipe(Option<Box<dyn io::Write + Send + 'static>>)} after getting some sleep ^^

@TilCreator
Copy link
Contributor Author

I'm quite happy with this version as it breaks very little if anything at all and it feels like a simple extension of the old target method.
Now I just need a better example as the current one is just confusing and not super practical.

@TilCreator TilCreator marked this pull request as ready for review March 4, 2021 10:56
@mainrs
Copy link
Contributor

mainrs commented Mar 7, 2021

I can take a closer look an Tuesday, up until then I don't have enough time for a full review :)

Copy link
Contributor

@mainrs mainrs left a comment

Choose a reason for hiding this comment

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

The rest looks decent. Maybe @jplatte could look over again as he was the initial reviewer, and a second pair of eyes is always good ;)

That being said, sorry that it took me that long.

src/fmt/writer/termcolor/shim_impl.rs Outdated Show resolved Hide resolved
*/

#[macro_use]
extern crate log;
Copy link
Contributor

Choose a reason for hiding this comment

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

2018 idoms, you should be able to just call use log::{info, error, warn};. Is there a policy in-place for examples and what edition they should target? If not, I would use the newer syntax.

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 would agree that this should be changed, but all other examples are very similar and use this line. So a bulk change of all the examples would be better. Should I still change it?

examples/custom_target.rs Outdated Show resolved Hide resolved
examples/custom_target.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
TilCreator and others added 3 commits March 13, 2021 23:05
Co-authored-by: SirWindfield <[email protected]>
Co-authored-by: SirWindfield <[email protected]>
Co-authored-by: SirWindfield <[email protected]>
@TilCreator
Copy link
Contributor Author

thx @sirwindfield (also for fixing my typos ^^)

@jplatte
Copy link
Contributor

jplatte commented Mar 14, 2021

I can have a second look, sure. Probably going to take a while for me as well.

@jose-acevedoflores
Copy link

I've been playing around with this pr since I need support for logging to a file and this works great for my use case!

I did have one question about the possibility of having multiple targets like stdout and a file. Is this something out of scope for the goals of this library or is it something that could be entertained ?

@TilCreator
Copy link
Contributor Author

(I'm just a contributor, not a maintainer)
I think this is possibly better implemented by the user, it sounds like a quite specific use case. (Maybe this could be added to the example (and I'm still not entirely happy with the example)?)

Comment on lines +118 to +119
target_type: TargetType,
target_pipe: Option<Arc<Mutex<dyn io::Write + Send + 'static>>>,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why split the target into two fields and introduce a new TargetType type? I think target can just be wrapped in Option for the build method to work (where you can then use self.target.take().unwrap_or_default() to get the actual value).

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 did try that, because I would like it way more that way, too. But the Target gets passed (and cloned) everywhere (for color checking and the shim_impl) that is why TargetType needs Clone, Copy, Debug, Eq, Hash, PartialEq implemented which is hard to impossible with dyn io::Write + Send + 'static.

@@ -70,46 +71,72 @@ impl Formatter {

pub(in crate::fmt::writer) struct BufferWriter {
inner: termcolor::BufferWriter,
test_target: Option<Target>,
test_target_type: Option<TargetType>,
target_pipe: Option<Arc<Mutex<dyn io::Write + Send + 'static>>>,
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you explain why Arc<Mutex<>> is needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because the pipe is still partly owned by the Builder (it doesn't get deconstructed on build()).

@jplatte
Copy link
Contributor

jplatte commented Apr 28, 2021

I'm still planning to have a look at this again, hopefully this or next week.

@jplatte
Copy link
Contributor

jplatte commented Jun 11, 2021

Merged in #204.

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.

4 participants