cookiecutter template inheritance

[vaab]

I'm highly interested in cookiecutter template inheritance.

It doesn't seems complicated to implement, and I might try it soon.

My first reflection is that it requires to change some core principle, although they are implementable while keeping backward compatibility.

• use of YAML in cookiecutter.yml, adds a inherit keyword, allowance for multiple inherited value
  doesn't seem difficult to handle:

    inherit:
      cookiecutter-py: https://github.com/audreyr/cookiecutter-py
    context:
        ...

• the name of the main template directory should not be managed as it is today. It should be a fixed name (like say 'src') and the final name of the actual created directory should be given by other means (config file probably.
  • Why ?
    • (unrelated) the current way of detecting this directory is clunky to say the least, and without good justification it seems.
    • In some ways, allowing to set the name from the template dir is somewhat awkwards, and as a result nearly every body don't use that feature and ends up with a {{cookiecutter.repo_name}} or something equivalent. As a user, I might want to specify my target directory name at the CLI level also. Today, the 'repo_name' feels that it should be a command line argument more than queried variable for more than one reason (you don't need to set it per default in your config file for instance).
    • To support inheritance, for instance, you want your 'cookiecutter-python' project to define a generic set of file. But how to name your root dir ? Your 'cookiecutter-django' template will want to override this name with 'django-{{name}}'.

Thank you for your great work on cookiecutter. Don't be offensed by my reflections. And please consider giving me a feedback on how do you feel about these ideas.

[pydanny]

Neat idea but I'm closing this issue because:

1. This changes some of the concepts of this project, that it is language, tool, framework agnostic in its output.
2. Having a src directory is very opinionated. More opinionated then Cookiecutter's pattern.
3. Inheritance would add complexity to the project, something we strive against.

All this said, it's a fascinating idea. More like this please! 😄

[vaab]

I don't have the feeling that you've even read/understood my proposition as 2 of your remarks does not seem to even apply to my proposition (1. - care to be more specific ? and 2. - making a point about the name of this directory is not pertinent, this is an internal convention and does not impose anything in the resulting project generated by cookiecutter). Only point 3 could apply but is a very general statement with no technical value and no objective ground and could be applied to any new or old features...

But I feel that current cookiecutter management of community is probably closed enough to my taste (after many PR un-answered for years, closed randomly, with what I perceive as poor technical comments with usually low added value) for me to stop pushing here my code, comments, idea or bugfixes or even trying to argument anything else here. I'm very aware that it won't be a loss at all on your side, that's exactly why I don't feel I should spend more effort here.

You have a nice project, I'll probably continue to use it with my added patches... I wish you to achieve your goals with that project !

[ssteinerx]

@vaab I am thinking about the same thing, but I've not gotten into implementation details at all yet: https://github.com/ssteinerx/cookiecutter-django-flux

[gotcha]

@vaab Do you still use cookiecutter ? If the patches you mention hereabove are related to template inheritance, are they visible somewhere ?

[vaab]

@gotcha I sent a few patches on different topics as PR a long time ago, this is what I was referring to in my last message on this thread when I mentionned patches. Unfortunately for you here, I didn't code anything around template inheritance but I'm still using cookie-cutter exclusively with a personal fork with my PRs. If you happen to code anything related to this, please keep me in touch.

[Luttik]

This seems like two separate issues now. One is inheritance which I would absolutely love. Being able to have different project-template for different types of projects that all depend on the same company-wide package-template would be lovely. I think this should be doable without adding in language-specific code. I could see a structure where:

1. You add both the files of the parent and child project (recursively merging the folders)
2. On a conflict:
   a. Use the child file by default
   b. Use jinja's templating inheritance if the child projects file starts with {% extends "filename" %}

I don't think these additions would result in language-specific features, a significant change in cookiecutters patterns, or a higher skill-floor (it only adds a bit of complexity if you want to use these features)

The second issue that @vaab mentions is the need to start the cookie-cutter project with folder that has a templated name. I think while there are valid arguments to be made there we should ignore that requests since it barely has any connection to the name of this issue.

@pydanny would you consider opening the issue such that we can discuss the possibility of inheritance in cookiecutter without worrying about the other request?

[simobasso]

Hi there!

Just opened #1485 that implements templates inheritance using jinja's templating inheritance as described in #1484.

If you are interested please have a look! 😊