Hi, Brett. I was excited to see your blog post about planter.
Creating templated project directories is something that I do often. My tool of choice over these past years has been to use cookiecutter when I need a “variable” to be propagated into the structure/filenames, or simply to drag-n-drop an empty folder hierarchy if I just need the structure created. Drag-n-drop is nice because it will also carry over the custom icons (folder colors).
How would you differentiate planter from cookiecutter? What use cases did cookiecutter not cover for you that you decided to make your own tool?
Thanks for sharing the fruits of your labor with us fellow nerds.
I actually hadn’t seen cookiecutter before. Looks almost exactly the same, and without actually trying it out I can’t tell if there’s any specific benefit to Planter. I don’t see that cookiecutter offers a lot of string modifiers and if/then logic, though, and Planter has multiple choice options with logic based on choices, so unless cookiecutter does those things, I would still prefer my own solution. Maybe it does, though, just did a cursory look through the docs.
If I’d known about cookiecutter I might not have put the time into Planter. But… I probably would because it was fun and I like coding projects :).
I agree with you that cookiecutter and planter are similar.
Similar to your planter, cookiecutter uses the concept of a template consisting of a hierarchy of folders and files. Within folders and files, a variable may be specified. In Planter, I believe you are using %%variable%% for the variable, whereas Cookiecutter (based on Jinja) is using {{ variable }}. The variable later gets populated by user-specified content at the time when the Cookiecutter template is executed to create a new project.
I have only used simple if-then-else logic myself (basically to name files or select which files to include in the generated project), but the Cookiecutter docs show advanced use cases that are possible using Jinja’s {%- if cookie cotter.variable == "X" -%} conditional expressions and Boolean variables to really customize the generated content of files.
As for string modification, Cookiecutter seems to support it because Jinja supports it. The example that is given in the Cookiecutter docs is as follows:
The values (but not the keys!) of cookiecutter.json are also Jinja2 templates. Values from user prompts are added to the context immediately, such that one context value can be derived from previous values.
Basic example:
Python packages show some patterns for their naming conventions:
a human-readable project name
a lowercase, dashed repository name
an importable, dash-less package name
Here is a cookiecutter.json with templated values for this pattern:
{
"project_name": "My New Project",
"project_slug": "{{ cookiecutter.project_name|lower|replace(' ', '-') }}",
"pkg_name": "{{ cookiecutter.project_slug|replace('-', '') }}"
}
If the user takes the defaults, or uses no_input, the templated values will be:
my-new-project
mynewproject
Or, if the user gives “Yet Another New Project”, the values will be:
yet-another-new-project
yetanothernewproject
Here’s a good example of a modern Cookiecutter template for creating new Python projects that utilize the uv package manager: cookiecutter-uv
@ttscoff , I remain super-interested in exploring Planter. You always make such interesting tools, and I learn so much from you.
Yeah, it sounds like I definitely reinvented the wheel on this one. But it was fun, and take a look and see if it actually offers anything cookiecutter doesn’t. I’ll dig into it after I’m back from this work trip and if I don’t see any reason for planter to exist, I’ll add a link and note to the project page
