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

Standardize Logging #1152

Open
rm-dr opened this issue Feb 16, 2024 · 2 comments
Open

Standardize Logging #1152

rm-dr opened this issue Feb 16, 2024 · 2 comments
Assignees
Labels
chore Minor cleanup, version bumps, etc

Comments

@rm-dr
Copy link
Contributor

rm-dr commented Feb 16, 2024

Tectonic's logging StatusBackend is a bit messy. The log crate provides a much better logging API, and would work very well for our use-case.

I propose we replace tectonic-status-base with log and log4rs. It's much more ergonomic than the current solution, and it makes tectonic-as-a-library easier to use.

(I'd open a PR, but I don't want to start working on such a big change without some discussion.)

@rm-dr rm-dr self-assigned this Feb 16, 2024
@pkgw
Copy link
Collaborator

pkgw commented Feb 20, 2024

Let's see ... I'm trying to dig into my memory of why I designed things the way I did, when I was initially putting the code together.

If I'm remembering correctly, the motivation was mainly about being able to have precise control over the formatting of the different kinds of messages that would be emitted to the terminal during compilation. Effects achieved with functions like note_highlighted or dump_error_logs were things that seemed like they would be hard to achieve in a standardized logging framework.

Ah, yes, from the crate-level docs of the crate: "A lot of the functionality here could be replaced by generic logging frameworks, but we do have some extra hooks to help support a nice user experience for the Tectonic CLI tool."

That's not to imply that it wouldn't be valuable to have standardized logging plumbed through the Tectonic crates as well. But I do generally feel that generic logging frameworks generally lead to CLI output that's not as refined as what you can get from more customized approaches. So to that extent, I see a motivation for the continued use of the "status" framework. But I wouldn't be surprised if there was a way to at least integrate it with the standard logging frameworks in a better way.

@rm-dr
Copy link
Contributor Author

rm-dr commented Feb 21, 2024

Rust's logging api is fairly flexible, most of status-base would be easy to implement.
note_highlighted is the only feature that isn't easy to copy, but it might be possible with the kv_unstable feature of log.

(This makes sense: log is backend-independent, and highlighted text is only relevant in terminal output assuming the terminal even supports colors.)

However, if we want progress bars or any other fancy terminal eye-candy, we'll have to use something like status-base.

It might be a good idea to use a combination of both: log exclusively inside all tectonic components, and a high-level pretty tui implemented ONLY in the topmost cli crate. This makes tectonic-as-a-library more ergonomic (by decoupling ui logic from compile logic), and lets us easily run tectonic in a headless "log-to-file" mode for automated builds.

@rm-dr rm-dr added the chore Minor cleanup, version bumps, etc label Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Minor cleanup, version bumps, etc
Projects
None yet
Development

No branches or pull requests

2 participants