Skip to content

Commit 707334a

Browse files
committed
docs: improve readme overall
1 parent 319e155 commit 707334a

File tree

1 file changed

+70
-97
lines changed

1 file changed

+70
-97
lines changed

README.md

Lines changed: 70 additions & 97 deletions
Original file line numberDiff line numberDiff line change
@@ -30,18 +30,71 @@
3030

3131
# cookiecutter-robust-python
3232

33-
**A template making robust design the default**
33+
**A template optimizing for best practices without sacrificing adaptability.**
3434

35-
**[📚 View Documentation](https://cookiecutter-robust-python.readthedocs.io/)** | **[🐛 Report a Bug](https://github.com/robust-python/cookiecutter-robust-python/issues)** | **[✨ Request a Feature](https://github.com/robust-python/cookiecutter-robust-python/issues)**
35+
---
36+
37+
38+
<details open="open">
39+
<summary>Table of Contents</summary>
40+
41+
- [About](#about)
42+
- [Key Features](#key-features)
43+
- [Getting Started](#getting-started)
44+
- [Prerequisites](#prerequisites)
45+
- [Usage](#usage)
46+
- [Project Setup](#project-setup)
47+
- [Roadmap](#roadmap)
48+
- [Why does this project exist?](#why-does-this-project-exist)
49+
- [Contributing](#contributing)
50+
51+
</details>
52+
53+
## About
54+
55+
---
56+
57+
**[cookiecutter-robust-python]** is a template made with the understanding that **project needs change over time**.
58+
59+
The **[Robust Python Cookiecutter]** aims to provide **best practice tooling/CICD** within a structure designed for **future adaptability**.
3660

3761
---
3862

39-
## Quick Start
63+
### Key Features
64+
- Uses [cruft] to allow for easily transitioning:
65+
- Using [maturin] vs not
66+
- repository/CICD provider ([github], [gitlab], [bitbucket])
67+
- Supported Python Versions
68+
- Out of the box support/testing for major OS's (windows, linux, macos) and all currently supported [python] versions
69+
- Automated template demos for integration testing generated CICD
70+
- Rich documentation explaining [tooling decisions] and rationale
71+
- and just about any other typical CI workflow you can think of (linting, release process, security, etc.)
72+
73+
### Tooling Summary
74+
- [cruft] for project generation/update
75+
- [uv] for dependency management
76+
- [nox] for CI execution
77+
- [commitizen] for version/changelog management
78+
- [ruff] for linting/formatting
79+
- [basedpyright] for type checking
80+
- [pip-audit] for security vulnerability checking
81+
- [maturin] (optional) for rust integration when needed
82+
83+
## Getting Started
4084

4185
### Prerequisites
42-
The only requirement is [uv].
86+
The only requirement is installing [uv].
87+
88+
Besides that, it may be useful to install the following to avoid `uvx` installing dependencies at unexpected times:
89+
```terminaloutput
90+
uv tool install nox
91+
uv tool install cruft
92+
uv tool install ruff
93+
uv tool install basedpyright
94+
uv tool install maturin
95+
```
4396

44-
### Create Your Project
97+
### Usage
4598
Navigate to where you want to create your project and run:
4699

47100
```bash
@@ -72,21 +125,6 @@ uvx nox -s setup-remote
72125

73126
**Quick setup:** Run `uvx nox -t env` to execute all environment setup tasks at once.
74127

75-
76-
## Most Notable Features
77-
- Modern tooling with [uv], [ruff], [cruft], etc.
78-
- Built for supporting most OS's (windows, linux, macos) and all currently supported [python] versions
79-
- Platform agnostic CI/CD ([github], [gitlab], [bitbucket])
80-
- CI/CD that parities local [nox] sessions for all [python]
81-
- [maturin] support that can be added at any time during the project's lifecycle
82-
- Designed to be a maintainable template over time through the use of automated demos and integration tests
83-
- Rich documentation explaining tooling decisions and rationale
84-
85-
For a general overview of where we are at with this template, please see the [roadmap](#roadmap) section.
86-
87-
## Example Output
88-
For an example of this template's output, please visit the [demo](https://github.com/robust-python/robust-python-demo) which is kept up to date with the current state of this template.
89-
90128
## Roadmap
91129

92130
This is a really brief/condensed idea of what is planned for this template, and where it stands currently:
@@ -103,18 +141,18 @@ This is a really brief/condensed idea of what is planned for this template, and
103141
- [ ] Ensure maturin template works locally
104142
- [ ] Add modified CI/CD for the maturin version
105143
- [ ] Add CI/CD for the cookiecutter itself
106-
- [ ] Add github actions to automate demo publishing on merge to main or develop in cookiecutter
107-
- [ ] Better define out templates for issues, pull requests, etc.
144+
- [x] Add github actions to automate demo publishing on merge to main or develop in cookiecutter
145+
- [x] Better define out templates for issues, pull requests, etc.
108146
- [ ] Improve generated changelogs
109147
- [ ] Clean up documentation and make it readable
110148
- [ ] Possibly swap documentation to follow MADR (Maybe during clean up process, but low priority for the time being)
111-
- [ ] Move to an organization (Will be done whenever there are other users besides myself)
149+
- [x] Move to an organization (Will be done whenever there are other users besides myself)
112150
- [ ] Add any missing automation for administrative tasks
113151
- [ ] Designate backup plans for the projects lifecycle over time
114152
</details>
115153

116154

117-
# Why does this project exist?
155+
## Why does this project exist?
118156

119157
Unfortunately, the [Hypermodern Python Cookiecutter] is no longer maintained nor modern.
120158
While it will always have a place in my heart, there have been far too many improvements in Python tooling to keep using it as is.
@@ -125,86 +163,19 @@ to new tooling such as [ruff], [uv], [maturin], etc., I found the process of upd
125163
The [Hypermodern Python Cookiecutter] remains as a fantastic sendoff point for devs interested in building a 2021-style Python Package. However, there were
126164
a handful of issues with it that prevented it from being able to adapt to new Python developments over the years.
127165

128-
# Okay, so what's different this time?
129-
130-
The [Robust Python Cookiecutter] exists to solve a few main concerns
131-
132-
- [Template Update Propagation](#template-update-propagation)
133-
- [Project Domain Expansion](#project-domain-expansion)
134-
- [Documenting Tooling Decisions](#documenting-tooling-decisions)
135-
- [CI/CD Vendor Lock](#cicd-vendor-lock)
136-
- [Project Neglect](#project-neglect)
137-
138-
## Template Update Propagation
139-
140-
One of the main issues I encountered with [my personal fork] of the [Hypermodern Python Cookiecutter] was that any change
141-
I made to my repos would mean a later conflict if I tried to rerun [cookiecutter] to sync a change from a different project.
142-
143-
Thankfully, [cruft] exists specifically to help with this issue. It enables us to periodically create PR's to add in any fixes
144-
the [Robust Python Cookiecutter] may have added.
145-
146-
Additionally, extra care is put in to use tooling specific config files whenever possible to help reduce merge conflicts occurring
147-
in the pyproject.toml.
148-
149-
## Project Domain Expansion
150-
151-
Now, I'm not one to advocate for mixing languages in a project. However, there is a unique case that has arisen with the creation of [maturin].
152-
153-
There are a plethora of great projects such as [ruff], [uv], [polars], [just], etc. all making use of [maturin] to get the performance improvements of [rust] while
154-
submitting their package to both pypi and crates.io
155-
156-
Now, this definitely is not required by any means to make a good Python package, however this pattern only seems to be picking up momentum and has honestly been a massive boon
157-
to Python's ecosystem overall.
158-
159-
That being said, it's generally good practice to avoid the complexity of this dual language system unless you actually need the performance bump for your use case. However knowing ahead of time if performance
160-
will be an issue is rather tricky, and a much easier route is to just prepare as though you _might_ swap to it some day.
161-
162-
The [Robust Python Cookiecutter] includes an `add_rust_extension` flag that not only toggles [maturin] vs a traditional Python package,
163-
but that can be used in combination with [cruft] to swap to [maturin] at any time with just about no risk to CI/CD / etc.
164-
165-
Additionally, the [Robust Python Cookiecutter] is designed with both normal and [monorepos] in mind. So whether you need to just add
166-
a quick [rust] module for performance or you are trying to publish a series of crates and packages, either case will be handled using a setup inspired by [polars].
167-
168-
## Documenting Tooling Decisions
169-
170-
One of the really stand out features of the [Hypermodern Python Cookiecutter] was its incredibly detailed documentation.
171-
It did a pretty great job of describing the tooling to use, but there was a distinct lack of **_why_** these decisions were made.
172-
173-
It may seem like a small detail, but detailing why a decision was made has an incredibly important effect on the maintainablity of the template.
174-
175-
#### **It allows maintainers to check if a decision should change in one click.**
176-
177-
Rather than having to go through a mini crusade to determine whether we use [poetry] or [uv], we can just point to the
178-
[existing reasoning](https://cookiecutter-robust-python.readthedocs.io/en/latest/topics/02_dependency_management.md#option-2--term--poetry) to see if it still is true or not.
179-
180-
Overall, it's rather rare that people debate over tooling for no reason. Most things have merit in some cases, and a large goal of this template is identifying the tools that have the most merit in almost all cases.
181-
182-
## CI/CD Vendor Lock
183-
184-
Now don't get me wrong, I love [github-actions] and do pretty much everything in my power to avoid [bitbucket-pipelines].
185-
However, not all jobs have the luxury of GitHub, and I would love to be able to just use the same template for both my personal and professional projects.
186-
187-
The [Robust Python Cookiecutter] focuses on being as modular as possible for areas that connect to the CI/CD pipeline. Additionally, there will always be either alternative
188-
CI/CD options or at a minimum basic examples of what the translated CI/CD pipeline would look like.
189-
190-
Finally, the main reason that this task is even possible is that the [Robust Python Cookiecutter] mirrors all of the CI/CD steps in it's local dev tooling.
191-
The local [noxfile] is designed to match up directly with the CI/CD each step of the way.
192-
193-
The [Hypermodern Python Cookiecutter] did this where it could afford to also, however the lack of [uv] meant it would significantly increase CI/CD times if done everywhere.
194-
Thankfully now we can spin up a venv with a tiny fraction of the overhead that used to exist.
166+
The goal is for [cookiecutter-robust-python] to fill the gap that exists for a best practices template that is structured to be adaptable from the start.
195167

196-
## Project Neglect
197168

198-
This is most certainly not a knock against claudio. The work they did on [cookiecutter-hypermodern-python] laid the way for countless other devs to start
199-
implementing best practices in their python packages.
169+
## Contributing
200170

201-
However, Open Source work is draining, and is especially so for a project template including metacode.
171+
For more information on contributing to the [Robust Python Cookiecutter], please visit the [contributing] docs.
202172

203-
I can guarantee that if the [Robust Python Cookiecutter] ever sees any number of users, I will immediately transfer it to an organization to enable at least a handful
204-
of trusted individuals to ensure the project is taken care of.
205173

174+
[basedpyright]: https://github.com/DetachHead/basedpyright
206175
[bitbucket]: https://bitbucket.org
207176
[bitbucket-pipelines]: https://support.atlassian.com/bitbucket-cloud/docs/write-a-pipe-for-bitbucket-pipelines/
177+
[commitizen]: https://commitizen-tools.github.io/commitizen/
178+
[contributing]: CONTRIBUTING.md
208179
[cookiecutter]: https://cookiecutter.readthedocs.io/en/stable/
209180
[cookiecutter-hypermodern-python]: https://github.com/cjolowicz/cookiecutter-hypermodern-python
210181
[cookiecutter-robust-python]: https://github.com/robust-python/cookiecutter-robust-python
@@ -219,12 +190,14 @@ of trusted individuals to ensure the project is taken care of.
219190
[my personal fork]: https://github.com/56kyle/cookiecutter-hypermodern-python
220191
[nox]: https://nox.thea.codes/
221192
[noxfile]: https://github.com/robust-python/cookiecutter-robust-python/blob/main/%7B%7Bcookiecutter.project_name%7D%7D/noxfile.py
193+
[pip-audit]: https://github.com/pypa/pip-audit
222194
[poetry]: https://python-poetry.org/docs/
223195
[polars]: https://github.com/pola-rs/polars
224196
[python]: https://www.python.org/
225197
[robust python cookiecutter]: https://github.com/robust-python/cookiecutter-robust-python
226198
[ruff]: https://docs.astral.sh/ruff/
227199
[rust]: https://www.rust-lang.org/learn
228200
[rye]: https://rye.astral.sh/
201+
[tooling decisions]: https://cookiecutter-robust-python.readthedocs.io/en/latest/our-chosen-toolchain.html
229202
[install uv]: https://docs.astral.sh/uv/getting-started/installation/
230203
[uv]: https://docs.astral.sh/uv/

0 commit comments

Comments
 (0)