Make it pluggable

[barseghyanartur]

Description

This project is awesome. I like it as is, but there's a tiny feature I want to add...

I think amount of forks speaks for itself.

Rationale

• Nobody likes maintaining a fork (hell).
• Everybody likes to customize things.

The proposal

• Turn features into plugins. If plugin is enabled, you will be asked about it in the project setup wizard.
• Have a default set of plugins enabled.
• Make it possible to override the settings (either in some global YAML or INI config).

[luzfcb]

@barseghyanartur It's an interesting idea, but the real question is how to implement, test all possible combinations to make sure that's everything works as expected and maintain it for an undefined time.

This project is maintained by volunteers, who make use of their precious free time to try to help other people for free to have a good base to start a project.

The cookiecutter itself does not have a concept of pluggable templates and because of that, although I think it's an interesting idea but unfeasible due to lack of tools.

[Andrew-Chen-Wang]

I've been thinking of something similar. But instead of having to test all these combinations it would probably just be better to have pluggable plug-ins such that these plug-ins do not interfere with any combinations and are independent

[browniebroke]

That's an old feature request, yes (see #784) but as @luzfcb said, it's more of a limitation of the cookiecutter tool itself. Unless you have a practical suggestion to overcome this?

do not interfere with any combinations and are independent

Even if we are limited by the tool, it would be nice to make each option a bit more independant, I agree. It would help with maintainability in the long run, and if cookiecutter one day supports plugin, it would make things easier to migrate (although that's a long shot).

One typical example is our options related to the front-end asset pipeline: we currently have 3 seemingly independant options which may actually lead to a broken setup in some cases (see #3535 for a suggestion to improve it - feedback welcome).

[Andrew-Chen-Wang]

We could use the post hook? So one of our options is "plugins" and we list all plugins we're aware of. The user doesn't need to choose any and provide one that isn't listed. The user will provide the plugins by name (only if it's an option in the cookiecutter.json file) or by link in CSV fashion.

The way plugins should work is similar to Middleware. As they are independent, they will have their own cookiecutter project configuration that we run in the post hook installation. The plug-in generates its code. Where does the code go? If it's a new file, it just adds the file to the already generated cookiecutter django project. If the plug-in code needs to be in an existing file, since it's an independent plug-in, it appends to the end of an existing file.