Support single-file templates

[vfaronov]

This may be out of scope for you, but personally I like the ability to instantiate single files—such as scripts—without any containing directories. As far as I understand, this is currently not possible with Cookiecutter. Could be a magic option in cookiecutter.json, like "__single_file__": true.

[michaeljoseph]

#10 is the oldest and now contains enough info for implementation.
Closing.

[retr0h]

Could someone explain how this can be accomplished? I have looked through the linked issues/PRs and do not see a reference on how to support single file templates. It appears this is no longer an issue, but see no good examples.

/cc @michaeljoseph

[michaeljoseph]

@retr0h, yeah looks like there was some discussion in #10, but nothing's come out of it.
Re-opening.

[talwrii]

Hey, this issue has the duplicate but isn't a duplicate anymore. I would remove the tag but I'm not allowed (only maintainers).

[talwrii]

I've added a pull request for a first cut of this feature.

[talwrii]

Oops, accidentally self-hooray-emoji'd my own messages while trying to work out what the emoji meant "Hmm, what does that pizza emoji mean?". Please ignore...

[machinekoder]

@talwrii Can you please reference the PR.

[machinekoder]

Found it: #885

[machinekoder]

@talwrii I tried to rebase this branch on master: https://github.com/machinekoder/cookiecutter/tree/talwrii--freestanding-files--issue-35--2017-01-06

[talwrii]

Cool cool. Thanks for the heads up.

Hmm... I'm not sure what I think about this at the moment. I'm a little unhopeful about it getting it merged. I made the pull request more than a year ago for an outstanding issues with some discussion and tried quite hard to jump through the checklists and be a responsible citizen.

Also I'm rather disinclined to push too hard myself because of behaviour like this from the project maintainers:

"@vaab, this is your first and last warning about Code of Conduct violations against other contributors to Cookiecutter. The item of the Code of Conduct you are specifically violating is: [...]

Any future violations will result in an immediate banning from this project. While we encourage debate, we refuse to condone this kind of ongoing abusive behavior. We wouldn't allow this kind of treatment as paid employees, and we certainly won't take it as volunteers for an unpaid project."

(though perhaps this is a rather extreme example).

On the other hand I use this feature semi-regularly (though only for a couple of purposes) and find it useful. So will likely maintain this feature as a fork or implement it in some other means.

[bbugyi200]

Hello All. So I'm not sure if this is spam or not but I've been working on a small project (cookie) born out of the desire for this feature, so I thought everyone else might benefit from it.

The project's real focus has been allowing the quick initialization of scripts, but it works well with all filetypes. The template engine (if you can even call it that) is extremely minimal but it suffices for most of my purposes.

Whereas cookiecutter requires a more extensive setup and is more full-featured, I've been trying to focus on keeping the interface as quick and minimal as possible.

[talwrii]

@bbugyi200 An interesting idea. I think this might be a good approach to getting this sort of feature into some sort of "maintained" repository. Although running my own patched, out-of-date cookiecutter with this feature seems to be working fine for me :).

Some thoughts (I'm being a little opinionated here so would encourage you to take this all with a heap load of salt).

• I was trying to work out whether I needed to be able to create more than one file. Sometimes - for example I have a template that creates both a template readme and a file to convert this template into the main file. Of course... I guess I could just call this script twice. I can see why using the filenames (or possibly paths if you are happy to extend things) can dramatically simplify a lot of things. I wonder when you might get collisions here and how you would deal with namespacing.
• I think it's quite important to know what your tool does and doesn't do. I mean... all these tools are fairly simple really. Take some templates, interpolate some variables, done. The usefulness comes in the wrapping and the convenience. So I guess my question would be, how is your tool more feature complete than say - just calling jinja - how is it less complete than cookiecutter.
• The whole "reinventing the wheel" argument applies. I kind of think of the metaphor of "splitting off a wheel" for creating new projects.
• "I've been trying to focus on keeping the interface as quick and minimal as possible". So sure. The question is what intrinsic complexity you can hide or get rid of and whether the trade off is worthwhile.

---

Update: So I've just had a look at your tool to understand what is going on:

• It seems very much like your tool extracts out a specific subset of cookie cutter, namely the prompting for values and the creation of a file. That seems like it might be a natural idea
• Your approach for "managing" your cookiecutters is to make use of bash aliases / separate executables. This seems like a mnimal unixy approach. It does mean listing your templates becomes difficult... which is an operation that is kind of natural to want to do. I wonder if there is a nice way to do both. I guess you can just list maintain a list yourself somehow... though glueing the actions together does seem useful. I suppose this is the whole "code reuse / loose coupling" versus "pretty really well-integrated tool" thing. This makes me think of the whole "monolithic tools" versus "glued together shell script" way of doing things... I'm not sure I understand for myself which approach is better when.

So your tool does feel a lot more "unixy" and a lot less monolithic. I can see why you wrote it.

I do find being able to list my cookies useful. Also I'm suspicious that this all falls into "convenience" category... I guess loose coupling would be good. Does anyone have opinions.

I do realise I've introduced a whole load of discussion on another tool onto the cookiecutter list... oh well.

[bbugyi200]

@talwrii Thanks for such detailed feedback! I've tried to address each point as best as I can. Let me know if you have any other questions or advice!

I was trying to work out whether I needed to be able to create more than one file. Sometimes - for example I have a template that creates both a template readme and a file to convert this template into the main file. Of course... I guess I could just call this script twice. I can see why using the filenames (or possibly paths if you are happy to extend things) can dramatically simplify a lot of things. I wonder when you might get collisions here and how you would deal with namespacing.

Hmmm. I've never really thought about using multiple files (outside of a full-fledged cookiecutter project). I think the real value-added of the project how it makes writing system scripts easier. Some kind of multiple file feature would definitely be possible though if there was a lot of desire for it.

The whole "reinventing the wheel" argument applies. I kind of think of the metaphor of "splitting off a wheel" for creating new projects.

I would definitely be concerned about "reinventing the wheel" if I decide to add any more jinja-like templating features, but I don't think that single files will require such complexity.

As far as cookiecutter is concerned, I feel like cookie distinguishes itself in that it automates certain miniscule tasks that would normally be too insignifigant to care about in a larger project. For example, the fact that cookie will set the executable bit for a script and open it up in vim to a certain location (possibly already in INSERT mode) is a useful time-saver when you're just writing a quick on-the-fly script, but is perhaps not big-picture enough for a cookiecutter project. As another example, you can edit a template directly with cookie -e TEMPLATE, which is also something that is useful for a script template but not so much for a cookiecutter project.

Your approach for "managing" your cookiecutters is to make use of bash aliases / separate executables. This seems like a mnimal unixy approach. It does mean listing your templates becomes difficult... which is an operation that is kind of natural to want to do. I wonder if there is a nice way to do both. I guess you can just list maintain a list yourself somehow... though glueing the actions together does seem useful. I suppose this is the whole "code reuse / loose coupling" versus "pretty really well-integrated tool" thing. This makes me think of the whole "monolithic tools" versus "glued together shell script" way of doing things... I'm not sure I understand for myself which approach is better when.

I'm not sure what you mean when you say that "listing your templates becomes difficult". In fact, after reading your feedback, I thought that listing templates would be useful so I added a new command-line option: running cookie -l will now list all cookie templates.

[talwrii]

@bbugyi200

I'm not sure what you mean when you say that "listing your templates becomes difficult".

In your documentaiton, you seemed to use aliases for running templates. I was thinking that listing just these aliases might be difficult.

[bbugyi200]

@talwrii Ahhh. I understand now. Yeah that might be a bit harder. If they were just aliases you could use alias | grep cookie but that will only find the aliases and not the shell functions.

[almcc]

I realise this is a bit of a hack, but to get similar functionality as described, i.e. that of generating a single file, I just let cookiecutter create the directory like normal and then copy the file back a directory.

In my instance I just wanted a docker-compose file, so by post_gen_project.py looks like so:

import os
import shutil

PROJECT_DIR = os.path.realpath(os.path.curdir)
PARENT_DIR = os.path.dirname(PROJECT_DIR)

os.rename(os.path.join(PROJECT_DIR, 'docker-compose.yaml'),
          os.path.join(PARENT_DIR, 'docker-compose.yaml'))

shutil.rmtree(PROJECT_DIR)

The trick is not to create a directory that is going to be present already, but the user can override that at generation time.

[LeonardAukea]

Too bad this is not supported yet. It would be very nice to have native support. I solved the issue with with a post gen hook shell script but i'ts a hack.

cp -rf . ..
rm -rf -- "$(pwd -P)"

Furthermore, it requires that the directory name does not already exist.

[almcc]

I had forgotten that a hook could just be a shell script! Much cleaner solution.

[rwhitt2049]

For any wayward souls who find their way here. You can use this little hooks\post_gen_project.py hack to achieve single file templates. Note that if any subsequent hooks fail after this or if the rmdir fails, the single file won't be deleted, but the parent folder will be.

YMMV/alpha/works-on-my-machine

In your template, put the following in the file post_gen_project.py in the folder hooks

# hooks\post_gen_project.py
import os
import pathlib


os.chdir("..")
p = pathlib.Path("{{cookiecutter.file_name}}")
f = p.joinpath("{{cookiecutter.file_name}}.py")
f.rename("./{{cookiecutter.file_name}}.py")
p.rmdir()

[kurtmckee]

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

[acsr]

@jensens is there any recommended solution for the single file challenge that ended up in the docs. I guess not. The last entry was NOT 10 years old, but from 2022.

It would be a good idea to wrap this up this up in a final comment or a sticky one at the top with a hint at the end and maybe point to an external discussion or duplicate ticket.

Unfortunately I am not at the point of enlightment to do this (new to cookiecutter). Maybe later. Unless this may happen, any hints to tackle single file stuff with the current cookiecutter version?

My personal use case is to create a subtemplate to inject additional yaml subconfigs (using the python extension for pyyamlinclude) in an existing subdir and then add them as an include to a main yaml config one directory higher. But this should live only deeper in the tree and be generated by the parent cookiecutter but not included (isolated).
Because that adds additional stuff to the project tree I am in the layout phase of the architecture for the cookiecutter setup (jinja2 templates are already in place).

Ince we also need to create xml and bat files outside of the generated project config, the approach to generate locally and then move it around with post creation hooks may work (or not)

Any hints welcome...

[jonathanagustin]

I'm trying to do this with GitHub gists:
https://github.com/drengskapur/crumbcutter