Manim: Use a logging library

[leotrs]

The first step in this task is to replace print calls with a logging library. The next step is to add logging calls to places that don't have logging yet.

@eulertour mentions both Loguru and the stdlib logging library as options. I'm partial to stdlib logging.

[huguesdevimeux]

I’m too. It would save us from adding other dependencies.
Then do we keep the progressbar ?

[leotrs]

I think the progressbar can definitely stay, I think the progressbar is a good UI addition for users creating their videos. The logging library would be a catch-all ranging from info to users as well as debugging information for developers.

[PgBiel]

+1 for stdlib package. If anyone has more detailed input on this, though, please let us know

[kilacoda]

On discord we've settled for using rich. I'll be pushing the changes soon.

[leotrs]

Hi @kilacoda. Apparently, @huguesdevimeux, @PgBiel, and I are partial to the logging lib from stdlib. Can you please briefly summarize the reasons why rich was settled on?

[kilacoda]

Well, for one Rich allows us to format messages with more flexibility, such as adding colors to specific log elements (errors, warnings etc.), and makes things in general look better. It also provides its own markup language which can be used to format stuff like the Animation numbers.

Rich has more features too such as progress bars, tables, better tracebacks etc. which may be used later on if we want to say, remove tqdm.

TL;DR It looks good and seemed cool to the other guys so that's why.

[kilacoda]

Here's a little example of rich I've used in my manim renderer GUI. Looks better right?

[leotrs]

I do like the idea of handling logging and the progressbar from a single library.

I'm very very wary of using Yet Another Markup Language... but it seems it also supports markdown which is great.

Here is a link for reference.

[PgBiel]

Imo the usage of rich should be optional. We can easily implement colors by ourselves, without requiring yet another dep. We gotta keep those dep numbers down as much as possible. I'm not gonna lie, it looks like a cool lib, but we could do this (or most of it) using only stdlib, and it's not extremely necessary regardless..

[huguesdevimeux]

I agree with @PgBiel. Adding new dep is a bad idea.
But is implementing colors _that_ simple? Isn't that highly platform-dependent?

[SuperMaZingCoder]

@huguesdevimeux I have a library that is around 30 lines. The file only has to be included. It wouldn't be a dependency. (Look at download instruction #1); put the file in the manim-community directory.

@PgBiel Would this be the kind of thing that you were thinking about?

Link: https://github.com/CodeForeverAndEver/ColorIt

If needed, I can update it to include italics, bold, blinking text, etc.

[leotrs]

@CodeForeverAndEver thank you very much! I would be much more comfortable with using a established library such as logging or rich. The main point is that manim is meant to be used by many people, and we would rely on these established libraries' communities in case anything goes wrong with them. We are not really looking to include a new file just for the purpose of coloring log outputs. Please feel free to continue contributing to manim in other ways!

[SuperMaZingCoder]

Alright, sounds good 👍 I definitely get that and would feel the same way :D

[PgBiel]

I would be much more comfortable with using a established library such as logging or rich.

We would use this code together with logging, of course. @CodeForeverAndEver's code isn't a jack-of-all-trades, it's just, really, implementing colors in a simple way - it doesn't do the printing, which is logging's job. This is also extendable and lets us simulate something like colorama. Imo it's a good choice.

In the end, though, it might not really matter. If we decide on using rich and later stack up deps, this should be one that we can consider to remove, since we have an easy substitute to it. (However, it could be better to not depend on it from the start, since I'm not sure how difficult replacing rich code with our own color functions would be. Still, nothing stops us from doing so)

[leotrs]

I think ultimately the point is whether it is worth it to rack up dependencies. The benefits or using rich (or other alternatives) is to have colored logs and maybe consolidate the progress bar and logs under the same library. The disadvantages are that we add another dependency, and deviate from stdlib, and it's unclear how easy it would be to change to anything else in case we want to do so in the future.

I'm a bit torn, because I do like the colored logs. But not leaning either way for now.

[kilacoda]

Imho, we shouldn't really worry too much about the number of dependencies. It's whether the dependency is stable enough to meet our needs or not. Not adding a useful library just for the sake of not having too many libraries doesn't sound like the best idea to me. Dependencies grow as the requirements of a project grow, and while in the particular case of using rich I agree it's slightly somewhat not worth it to add an entire library for shiny, colorful logs, I just hope we don't continue fearing adding dependencies this way.

[PgBiel]

Of course, we should add dependencies as we need them (see my comment regarding attrs on #7). My opinion, to put it simply, is just that, for this case, it might not be necessary to actually add one. That's all. For future suggestions, these little deps could stack up and be, overall, rather an issue. However, with what we have so far, it is indeed possible to use rich. We should just be wary when discussing this kind of dependency on later issues.

[eulertour]

What's the status on this? Is anyone working on it?

[leotrs]

I initially assigned this to myself but can't work on it right now. How about @kilacoda ?