Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin/extension system #59

Closed
audreyfeldroy opened this issue Aug 31, 2013 · 9 comments
Closed

Plugin/extension system #59

audreyfeldroy opened this issue Aug 31, 2013 · 9 comments
Labels
enhancement This issue/PR relates to a feature request.

Comments

@audreyfeldroy
Copy link
Member

Make it possible to implement Cookiecutter plugins like:

This issue is dependent on #29 / #48.

I wonder if there would be a way to implement the plugin system such that #55 would be possible as a plugin. Not sure.

@bkonkle
Copy link

bkonkle commented Oct 22, 2013

You mention Danny's secret key plugin, but it appears the plugin itself is a secret? :-) I'd love to see it - secret key generation (and other similar extensions) would be quite nice.

@theladyjaye
Copy link

Is anyone opposed to setuptools entry points for handling this?

I'm going to assume the most natural place to something like this is for users to write their own Jinja2 Extensions so the custom tags can be used in their templating.

At first glance it doesn't seem too difficult to implement, I'd be happy to give it a go. Would pretty much just need to load everything in generate_files and set the extensions=[...] in the Jinja Environment initialization.

The other problem is Jinja Extensions are not exactly straight forward if you haven't done them before. Maybe start off with just simple Jinja Extenions, and then slowly over time add some CC helpers to make authoring them a little more straight forward in common cases?

@theladyjaye
Copy link

See Pull Request #103

@michaeljoseph michaeljoseph added this to the 1.1.0: Plugins milestone Nov 15, 2014
@brettcannon
Copy link
Contributor

I have somewhat run into a need for this as I have a template with some repeated, complicated Jinja templating that I don't want to make into one explicit Jinja plugin that people have to depend on so as to not gain a dependency on my template. It would be great if from some hook I could directly manipulate the Jinja context to inject my own items and plugins.

@hackebrot
Copy link
Member

Hi @brettcannon! 👋

Would your "own items and plugins" have any dependencies (other than what is already required by cookiecutter itself)?

@brettcannon
Copy link
Contributor

Nope. Honestly I just want a way to add more items programmatically after the user has entered their info.

To put this in concrete terms, I'm doing {{ cookiecutter.python_version|replace('.', '')|truncate(2, end='') }} across two files in multiple places (setting a variable when I can, but I'm still doing it multiple files), so I would rather do that manipulation in my pre-hook in Python code and store the result in the cookiecutter object so I could then access it from the Jinja code. So no dependencies at all since it's just straight-forward string manipulation that would be easier in Python than Jinja.

@hackebrot
Copy link
Member

Okay, cool. 🙇

I've used jinja2 assignments to help with that, but as you say, it doesn't work across multiple files.

Thanks for the feedback, I'll take it into consideration when we design a plugin system.

@hackebrot
Copy link
Member

I think this falls under the same category as #848. Assigning the Requires Sponsorship label until we have sponsorship for this project.

@insspb insspb added the 2.0.0 label Dec 22, 2019
@insspb insspb added this to To do in 2.0.0 Release via automation Dec 22, 2019
@ssbarnea ssbarnea modified the milestones: 1.1.0, 2.0.0 Mar 30, 2020
@ssbarnea ssbarnea removed the 2.0.0 label Mar 30, 2020
simobasso added a commit to simobasso/cookiecutter that referenced this issue Jan 2, 2021
implement a templates directory so a maintainer can use `extends`, `includes`,
`blocks`, `import` and `super` inside the cookiecutter project template
using jinja directly.

docs: https://jinja.palletsprojects.com/en/2.11.x/templates/#template-inheritance

closes: cookiecutter#1484
ref: cookiecutter#706
ref: cookiecutter#59
ref: cookiecutter#1004
simobasso added a commit to simobasso/cookiecutter that referenced this issue Jan 2, 2021
implement a templates directory so a maintainer can use `extends`, `includes`,
`blocks`, `import` and `super` inside the cookiecutter project template
using jinja directly.

docs: https://jinja.palletsprojects.com/en/2.11.x/templates/#template-inheritance

closes: cookiecutter#1484
ref: cookiecutter#706
ref: cookiecutter#59
ref: cookiecutter#1004
@simobasso simobasso modified the milestones: 2.0.0, Next May 21, 2021
@simobasso simobasso removed this from To do in 2.0.0 Release May 21, 2021
abvikg pushed a commit to Over-haul/cookiecutter that referenced this issue Jul 16, 2021
implement a templates directory so a maintainer can use `extends`, `includes`,
`blocks`, `import` and `super` inside the cookiecutter project template
using jinja directly.

docs: https://jinja.palletsprojects.com/en/2.11.x/templates/#template-inheritance

closes: cookiecutter#1484
ref: cookiecutter#706
ref: cookiecutter#59
ref: cookiecutter#1004
insspb pushed a commit to simobasso/cookiecutter that referenced this issue Jun 6, 2022
implement a templates directory so a maintainer can use `extends`, `includes`,
`blocks`, `import` and `super` inside the cookiecutter project template
using jinja directly.

docs: https://jinja.palletsprojects.com/en/2.11.x/templates/#template-inheritance

closes: cookiecutter#1484
ref: cookiecutter#706
ref: cookiecutter#59
ref: cookiecutter#1004
@kurtmckee
Copy link
Member

@jensens @pydanny @ssbarnea This issue is 10 years old. I recommend closing the issue.

@ericof ericof removed this from the 2.2.0 milestone Jun 13, 2023
@ericof ericof modified the milestones: 3.0.0, 4.0.0 Jun 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This issue/PR relates to a feature request.
Projects
None yet
Development

No branches or pull requests