Entry points, naming

[XorUnison]

As it stands both Manim and ManimCommunity have their entry module named manim.py, which is a problem when both are installed and in the environment variables, as there'll be two instances of manim.py to pick from. To keep ease of access I'd suggest something along the lines of renaming this manim.py to manimc.py (or something else) so that code can be quickly run on either installed version, which those developing here will likely want to do.

[leotrs]

So here's the thing: we have to find a solution such that it will fix the clash situation for devs (as we are more likely to have both versions installed), and will not change anything for the end user (for now, at least). The easiest way to do this is to allow our version to be ran in two different ways. In the usual python -m manim.py and also in a new way python -m manim-com.py. If you are a dev, you know you have to use the second one to avoid conflicts. If you are a user, regardless of which version you have, you use the first one.

[XorUnison]

From trying a simple renaming on my side I can already say there's gonna be a bit more needed. Even if I explicitly run the file from ManimCommunity, when both folders are in the env variables it'll actually use the manimlib from the main Manim, not ManimCommunity. This isn't all that surprising though when looking at manim.py, as it simply uses import manimlib, which will grab the first manimlib it's going to find.

[leotrs]

I think the problem is that currently, manim is ran directly from the manim.py file at the top level of the repo. There shouldn't be any .py files at the top level. Instead, the entrypoints should be designated using a setup.py file. All the .py files should go inside manimlib/, and only use local imports. In that way, our version will never try to do import manimlib which will grab the global installation.

See for example the numpy repo. All most of their imports are local.

[eulertour]

numpy seems to do global imports too, unless I'm missing something [1][2].

[leotrs]

Huh. That's interesting. I wonder if those are typos?

In that case, numpy would also have problems if there were two versions of numpy installed in the same machine.

Since we are trying to avoid that, I still think the best course of action (at least for now) is to try to import everything locally.

[leotrs]

Related: #15. Once that is merged, it'll be easier to work on adding the right entrypoints here.