Post

Astral-Powered Python Template: Fast, Clean, and Consistent

When working in a team, consistency matters. What if you could enforce project structure and tooling standards from the very start? In this post, I'll walk you through our Cookiecutter-based template that helps Python teams maintain structure, style, and best practices automatically.

We all write code a little differently. Folder layout, naming conventions, choice of linters, how dependencies are managed — those vary from person to person. But in a team setting, you don’t want every project to feel like a wild west of structure and tooling. When you’re reviewing someone else’s code, debugging across repositories, or onboarding a new teammate, having a uniform foundation can save hours of search.

Rather than relying solely on discipline, why not codify your structure, right from the project bootstrap? That’s precisely what our Python template (built using Cookiecutter) is designed to do: it generates a new project skeleton that already aligns with your team’s standards, while still allowing configurable choices.

If you’re already convinced and just want to try it, run:

1
cookiecutter https://github.com/arnaudguibbert/python-template.git

Then consult the project documentation for more setup tips.

What is Cookiecutter — and how does this template work?

Cookiecutter is a templating tool for project scaffolding: you write a “template” repository that contains placeholders and folder skeletons, then when someone runs cookiecutter <template-url>, they’re prompted for values to fill in those placeholders. It produces a fresh project structure customized to those inputs.

In short: you define a flexible blueprint once, and every new project is created by filling in those blanks. That’s how you automate consistency from day one.

Template capabilities & features

This template was designed to automate standard setup tasks that are common across Python projects. It streamlines the creation of consistent environments, bootstraps CI/CD pipelines, initializes standard development commands through a Makefile, and enforces a clear folder structure suitable for building Python libraries. Every files/folders content created by the template is extensively described in this documentation. Here’s an overview of what our template already supports:

  • Fully parameterized project metadata: project-name, CICD enabled… see the full list of parameters in this table.
  • Preconfigured tooling stack:
    • UV for Python version / environment management
    • Ruff as linter / formatter
    • Mypy type checking
    • pytest as the testing framework
    • Code coverage reporting
    • Makefile or task shortcuts for common dev workflows (environment creation, linting, type checking …)
  • Directory scaffolding: source code folder, tests folder, docs, etc.

In short: the template gives you a modern, opinionated starter project — but it doesn’t force every piece. You can opt in or out of features depending on your team’s preference. And even after the creation of the template, you are free to modify things.

Why this template, and where did it come from?

Over the years, I’ve worked across multiple teams — data scientists, data engineers, DevOps folks — and observed how much time is lost due to inconsistent project layouts, missing tooling, reinvented CI workflows, or mismatched linting rules. After iterating through team after team, I distilled a structure that balances flexibility and guardrails.

This template is the fruit of those experiences. It’s not perfect (and it might not suit every edge case), but it encapsulates a strong common configuration that works reliably in many Python projects. Because the template is open source, you and your team can extend or evolve it over time.

Interested in new features

If you find this template useful, a ⭐ on the GitHub repository means a lot. If you’d like to suggest improvements or new features, feel free to open an issue or a PR.

This post is licensed under CC BY 4.0 by the author.