Manim: Using Cleo instead of Argparse

[naveen521kk]

Currently, Manim uses Argparse for handling CLI arguments. It has been good but hard to maintain it, the currently introduced subcommands make it worse. Using something which was built for CLI management would help a lot of something like Cleo.

Cleo allows us to create beautiful and testable command-line commands. (Picked from docs) Where it uses docstrings to generate a command argument. (Bonus it allow autocompletion https://cleo.readthedocs.io/en/latest/introduction.html#autocompletion).

Many projects use this for CLI for example poetry.

[leotrs]

Yeah I've been thinking about ditching argparse too. Why Cleo and not Click?

[naveen521kk]

I didn't use any of the two. So your choice. For me, cleo looks more good.

[radiantly]

Hi, could I take up this issue?

However, it looks like click is more maintained compared to cleo so I think the switch should be made to click instead.

[leotrs]

@radiantly thanks so much for volunteering! This is a fairly major switch, so before you devote any time to it, I would like to have a discussion here about the pros and cons of each alternative. Why are we leaving argparse? Why should we take up any other library instead? Etc.

[cauebs]

Just to contribute to the discussion, you may want to take a look at typer, which wraps click :)

[leotrs]

@radiantly any updates on this? :)

[radiantly]

If the community comes to a decision, I can start working on the code.

A brief look at the options mentioned above:

• argparse - The codebase currently uses this, which as @naveen521kk mentions above, is good, but hard to maintain due to the lack of support for features like subcommands and lot of boilerplate code required.
• click - This is the most actively maintained library, if we were to switch, this would be first choice.
• cleo - Another library with a different philosophy when compared to click [1]. Not as actively maintained as click.
• typer - A wrapper around click that uses python annotations in an innovative way. The library is quite new and does not have 1.0 release yet, so I would suggest against using this for now.

[leotrs]

Thanks @radiantly. I do think that #620 does a good job at simplifying our argument parsing needs.

There is a trade-off here between how hard it is to maintain our own code vs how robust and supported the underlying library is. Right now, our code is hard to maintain, but there is TONS of support for argparse since it is part of stdlib. If we change to click (or other), our code may become cleaner, but we run the risk of going with something outside of stdlib (and adding yet another dependency).

@naveen521kk Can I ask you to please look at the argument parsing logic behind #620? Do you think that code is still too hard to maintain and we should incur in the risk of moving away from stdlib?

[naveen521kk]

I would suggest moving to another lib which is maintained would help us a lot in furture. For now, the current structure seems satisfying, but it would be difficult to add a new subcommand( I heard people working on addon system). Also, it will not hurt to add another dependency if it is more useful and keeps the logic simpler. Just because of an external dependency we should not make it hard to maintain also this looks like the same like that we picked rich.

[leotrs]

You are very convincing. I vote we go with the one that is the most supported, but let's do this after #620 is merged and stabilizes a bit.

Cc @ManimCommunity/core to hear from others.

[Aathish04]

I would _highly_ recommend moving to another command line parsing library other than argparse, if only for the reason that implementing new subcommands is unnecessarily long winded. click would be my first choice, since it seems to be the most well maintained library (other than argparse or optparse) out of all our options.