Refatoring of all functions that print to stdout/err so they accept a generic type that implements the Display trait

[MitchellBerend]

The following locations are potential candidates. These should not have a big impact on the rest of the code base, but they allow all the errors and other enums to have the same implementation strategy.

I would love some feedback on this.

• [x] src/infra/err.rs https://github.com/chshersh/tool-sync/blob/65b53bdbb51fcbe59d5c57a2b5bd1d9181ea6fcf/src/infra/err.rs#L3-L13
• [x] src/infra/err.rs https://github.com/chshersh/tool-sync/blob/65b53bdbb51fcbe59d5c57a2b5bd1d9181ea6fcf/src/infra/err.rs#L15-L31
• [x] src/infra/err.rs https://github.com/chshersh/tool-sync/blob/65b53bdbb51fcbe59d5c57a2b5bd1d9181ea6fcf/src/infra/err.rs#L33-L37
• [x] src/sync/prefetch.rs https://github.com/chshersh/tool-sync/blob/65b53bdbb51fcbe59d5c57a2b5bd1d9181ea6fcf/src/sync/prefetch.rs#L39-L42
• [x] src/sync/prefetch.rs https://github.com/chshersh/tool-sync/blob/65b53bdbb51fcbe59d5c57a2b5bd1d9181ea6fcf/src/sync/prefetch.rs#L44-L64
• [x] src/sync/progress.rs https://github.com/chshersh/tool-sync/blob/65b53bdbb51fcbe59d5c57a2b5bd1d9181ea6fcf/src/sync/progress.rs#L87-L93

[chshersh]

@MitchellBerend Thanks a lot for collecting all the usages of errors!

I marked this issue as blocked by #88 as the Display refactoring needs to happen first. Using Display instead of custom display() is definitely a welcome change 👏🏻

For this particular issue, it's a bit hard to evaluate whether it'll simplify the code or make it less maintainable. In theory, specifying the err_msg argument as some polymorphic type <Msg: Display> could open a road to future refactoring where we use some specialised trait for errors. E.g. std::error::Error or something from eyre.

But in any case, if refactoring proposed by this issue makes function signatures more generic and reduces usages of to_string() and display() on call sites, I'm happy to apply this refactoring 🆗

[MitchellBerend]

std::error::Error does not have the Display trait implemented and rust requires either the trait or the struct/enum to be defined in the crate itself, so I'm not sure if we can use that with the proposed change. Im not sure how eyre gets around this though.

[MitchellBerend]

Should we add a blocked label btw? That seems like a good idea so others don't waste time on issues that can't actually be solved yet.

[chshersh]

The blocked label sounds like a good idea! I've created it and added it to a blocked issue.

However, this issue is no longer blocked as #88 actually was already done by @zixuanzhang-x 😅

There's no way to specify what issue is blocking inside the label text. So I propose to put the "Blocked by #NUMBER" string in the beginning of every issue that is blocked by something else.