Fix imports

[leotrs]

The way that manim currently handles imports is far from optimal. This should be one of the first things we change.

In fact, this may be one thing preventing us from having standard manim and community-manim installed side by side on a single machine (see #6).

[eulertour]

This causes a problem with people using from manimlib.imports import * at the top of their files.

[leotrs]

That is exactly one of the things that I want to fix, and IMHO, using the idiom from ... import * should be discouraged.

[eulertour]

Regardless of whether people import * or not, there will be a conflict when people try to import classes from manimlib for their scenes.

[kilacoda-old]

What options do we have then? Because importing each file is not feasible given the way most animations make use of mobjects as needed. Having people do something like
from manimlib.mobject.geometry import Square is both time consuming and not really fun to do once you have a lot of mobjects in your scene.

[eulertour]

I think we just have to deal with having the conflict.

[leotrs]

The alternative is to tidy up the files in such a way that a couple imports will be enough. For most scenes, import manimlib as mn and then doing mn.Square , mn.play, mn.Scene, etc, should work. This is not as ugly as importing each thing once, though it does require to type mn.{thing} all over, but this is how python modules/namespaces are supposed to work anyway.
For more complicated scenes, it could be necessary to additionally do import manimlib.camera or some such.

@eulertour exactly what kind of conflict are you referring to? I'm not following.

[eulertour]

If someone has both versions of manim installed and puts from manimlib.imports import * at the top of their code, then they could end up running one version of manim and importing classes from another, even if our version only uses relative imports internally.

[kilacoda-old]

The alternative is to tidy up the files in such a way that a couple imports will be enough. For most scenes, import manimlib as mn and then doing mn.Square , mn.play, mn.Scene, etc, should work.

So like, importing them all into manimlib/__init__.py? Isn't that basically the same thing as importing from manimlib.imports but attaching an alias for manimlib?

[leotrs]

Ooooooh gotcha @eulertour, but I wasn't really thinking about that when I opened that issue. That is being discussed in #6.

For this issue, I think I mean concretely three different things:

1. It is highly unorthodox to have an imports.py file that just fills the namespace. Usually, these are in __init__.py, as @kilacoda suggests
2. All of the internal imports should be local, or at least as many as possible. I just don't think the code base makes good use of python's package architecture at all.
3. Shift from explicitly encouraging import * to explicitly discouraging it.

I think number 2. here would, maybe a little bit, address the issues of clashing with other manim versions (as discussed in #6), but would certainly not fix it.

[PgBiel]

1. It is highly unorthodox to have an imports.py file that just fills the namespace. Usually, these are in __init__.py, as @kilacoda suggests
2. [snip]
3. Shift from explicitly encouraging import * to explicitly discouraging it.

Imo it's an utility that the user can use if they want. It's mostly helpful for those who are new to manim and are not aware of its structure and just want to get things working. Note that the imports file does import more than just manim classes and whatnot: it also does so for numpy and other math stuff. Of course, the user can just import it by themselves, but again, it's quite helpful for newbies, so it should be an option, just not mandatory, neither discouraged.

To be clear, it is something we'd mention in some sort of tutorial or "Introduction" documentation page.

[leotrs]

Fair. I can see the use cases for allowing it / not discouraging it.

I agree this should be very clear in the introduction.

I still think the imports.py file needs to go :)