Feature plugins

[jsonvillanueva]

Motivation

Fixes #42

List of Changes

• New manim command, manim plugins with a couple of flags for listing and updating the file responsible for importing plugins.

• Documentation for installing/using/creating plugins

• Documentation that references, manim-plugintemplate, an external example that serves to as a guide for creating new plugins.

Explanation for Changes

Documentation is always good for new features. I can likely improve this in the future; just provide feedback on how thorough the documentation currently is/isn't and how quickly you were able to use my manim-plugintemplate on PyPI.

The manim plugins command was discussed on Discord which you can search for more details. It essentially allows us to easily modify what plugins manim imports -- also allows syntax highlighting/intellisense to continue to work.

The only gripe here is with git, this requires git update-index --assume-unchanged manim/plugins/__init__.py to ensure plugins import statements aren't tracked to git.

Usage

pip install manim-plugintemplate
manim plugins -ul

Here's a minimal example project I used to generate a scene using a custom_mobject/animation from the example plugin, manim-plugintemplate:

from manim import *

class Test(Scene):
    def construct(self):
        dot = Dot()
        self.add(dot)
        self.play(
            manim_plugintemplate.custom_mobject.EmitWaves(dot)
        )

The output of the video should look like the one here.

Testing Status

I've tested this on Windows 10, Manjaro Linux, and OS X which all work fine.

Further Comments

Maybe there should be an option to do from plugin_name import * in the manim plugins -u command instead of import plugin_name?

Acknowledgement

• I have read the Contributing Guidelines

[leotrs]

I like the direction this is taking. A lot. I've left a few comments as a first pass. I think the documentation can be beefed up a bit.

One point of discussion is how we are doing the importing. At first, I was expecting something like this:

from manim import *
from my_favorite_plugin import *

In this way, it is clear what comes from the core and what comes from the plugin (explicit is better than implicit and what not). This will also allow the user to choose which plugins will be imported on each scene, rather than importing all plugins for all scenes are currently done.

What are the benefits of doing it in the current form?

[jsonvillanueva]

One point of discussion is how we are doing the importing. At first, I was expecting something like this:

from manim import *
from my_favorite_plugin import *

In this way, it is clear what comes from the core and what comes from the plugin (explicit is better than implicit and what not). This will also allow the user to choose which plugins will be imported on each scene, rather than importing all plugins for all scenes are currently done.

What are the benefits of doing it in the current form?

I believe the main benefit in doing it in this current form is plugin discovery which was an area of concern brought up by @naveen521kk . That is, using the "manim.plugins" entry_point to define plugins that are available to the user's environment. This benefit is acted on via the manim plugins subcommand which uses the entry_point to list/update all available plugins.

I think this Manim functionality should mirror a browser being responsible for scanning/installing/knowing where to find addons, or a music DAW (if you're familiar) being responsible for having a directory for scanning vst/aax/au plugins. The browser might disable some of the installed addons, and the music DAW might not use all of the reverb/delay/chorus/piano/orchestral/synth plugins, but within the software they are responsible for enabling/disabling/using the extended functionality. I imagine Manim being used similarly where the the core software is responsible for managing plugins, That said, I'm really not too sure of other benefits... and the ability to toggle which plugins are "enabled/disabled", or imported/not is currently lacking in the subcommand. Maybe someone else has ideas for more benefits?

[leotrs]

I agree that the core should manage the plugins. At this point "management" seems to include discovery, installation, updating, listing. I'm still not convinced that we should inject all installed plugins on every scene. On the other hand, at this point this is harmless because there aren't any plugins to be installed 😅

I strongly suggest either: a) adding a way of disabling plugins, or b) keeping this PR to discovery/installation/updating/listing and not doing the importing.

[jsonvillanueva]

On the other hand, at this point this is harmless because there aren't any plugins to be installed 😅

Exactly haha!

I strongly suggest either: a) adding a way of disabling plugins, or b) keeping this PR to discovery/installation/updating/listing and not doing the importing.

Since we're in no rush, I'm fine with doing either. Also, it's worth note that --updating might be misleading. I intended for it to update the import list, but I could see how it would be read as updating each pluguin... but for that there's poetry update/pip. Here's the pros/cons I see:
a.) adding disabling plugins:

• pro: more functionality/fleshed out
• con: slightly longer development time (still need to add stronger documentation to both options)
• con: relies on argparse still which may end up getting rewritten by Cleo Using Cleo instead of Argparse #452

b.) Not doing the importing

• pro: Less redevelopment
• pro: Shorter development time
• con: less functionality

[leotrs]

When in doubt, I tend to lean toward less functionality and fast iteration. Let's try to think of this as an minimum viable product (MVP) and then quickly iterate on it and add the importing functionality if/when it is needed.

So my vote is for this to focus on the discovery/installation/listing and, importantly, documentation. (Thanks for clarifying the updating part.) If in the future we see that the importing/disabling is necessary, we can cross that bridge then.

This is my vote, but let's see what others think!

[jsonvillanueva]

When in doubt, I tend to lean toward less functionality and fast iteration. Let's try to think of this as an minimum viable product (MVP) and then quickly iterate on it and add the importing functionality if/when it is needed.

So my vote is for this to focus on the discovery/installation/listing and, importantly, documentation. (Thanks for clarifying the updating part.) If in the future we see that the importing/disabling is necessary, we can cross that bridge then.

This is my vote, but let's see what others think!

I'm in favor of the faster iterations as well. This also removes a bit of pressure off of my fork and allows others to takeover/contribute their ideas/code to the plugin functionality earlier on. I'll work on improving the documentation more (since much of it is in my PyPI plugintemplate atm, but some of it should exist in the Manim core as well... I believe I fail to mention the required entry_point for instance.

[leotrs]

I think this is a really good first pass in general. The one nitpick I will bring up is that currently, to use an installed plugin, the user must either import them manually (personally, this is my preferred way), or they have to manually modify plugins/__init__.py. In my opinion, at no point should we expect the end user to modify any file within manim's codebase directory tree. In the future, I believe we should use either the config system (and .cfg files, which live outside of the manim source code tree), or continue encouraging manual importing of each plugin.

But like I said, this is a good first pass.

[naveen521kk]

LGTM!

[leotrs]

Let's wait for @kilacoda before merging this.

[kolibril13]

https://github.com/ManimCommunity/manim/tree/addon-system
Just want to note that there is this addon-system branch. @kilacoda : Can this addon-system branch be deleted when this feature plugin is merged?

[naveen521kk]

If it's ok can this be merged @kilacoda ?

[kilacoda-old]

Yes.

[naveen521kk]

Done