|
2 | 2 | Why this Generator? |
3 | 3 | =================== |
4 | 4 |
|
5 | | -So, why would one opt for this Python Generator? |
6 | | - |
7 | | -It is **easy to use**, allowing the generation of a completely fresh new *Python Package Project*, |
8 | | -though a *cli*. |
9 | | - |
10 | | -You can immediately have a *ci* infrastructure and multiple platform-agnostic *shell* commands |
11 | | -working out-of-the-box, so you can focus on developing your *business logic* and your *test cases*. |
12 | | - |
13 | | -* It allows scaffolding new projects with a **Test Suite** included, designed to run *Test Cases* in **parallel** (across multiple cpu's) for *speed*. |
14 | | -* New Projects come with a **CI pipeline**, that triggers every time code is pushed on the remote. |
15 | | -* Supports generating projects suited for developing a library (*module*), a cli (*module+cli*) or a pytest plugin. |
16 | | -* The pipeline hosts a **Test Workflow** on *Github Actions* CI, designed to *stress-test* your package. |
17 | | -* Generates a *job matrix* that spawns parallel CI jobs based on factors:: |
18 | | - *python versions* |
19 | | - *operating system* and |
20 | | - *package installation methods* |
21 | | -* Extensively tested and built on established software, such as *cookiecutter* and *jinja2*. |
| 5 | +*So, why choose this Python Package Generator?* |
| 6 | + |
| 7 | +Robust CLI |
| 8 | +========== |
| 9 | + |
| 10 | +| You want an `easy-to-use`, `cross-platform` CLI. |
| 11 | +
|
| 12 | +- It offers an **1-click** command, or option for an interactive `wizard` |
| 13 | +- **Tested** on **15 different setups**, across multiple `Platforms` and `Python Interpreters` |
| 14 | + |
| 15 | + - **OS**: {Ubuntu, MacOS, Windows} X **Python**: {3.7, 3.8, 3.9, 3.10, 3.11} |
| 16 | +- Built on established software, such as *cookiecutter* and *jinja2* |
| 17 | + |
| 18 | +"DevOps": aka Automations and CI/CD |
| 19 | +=================================== |
| 20 | + |
| 21 | +| You want to focus on your *business logic* and *test cases*, in new Python projects. |
| 22 | +
|
| 23 | +- Scaffolded project is **one push** away from triggering its **CI/CD pipeline** on Github Actions. |
| 24 | +- **Continuous Deployment**, publishing at `pypi.org`, `Docker Hub`, and `Read The Docs` |
| 25 | +- Designed for **GitOps**, supporting various `automated developer activities` |
| 26 | +- **Automations** with same entrypoint for both **CI and Local** run, via `tox` |
| 27 | +- Stress-Testing, with **Job Matrix** spanning multiple `Python Interpreters`, `Operating Systems` |
| 28 | + |
| 29 | +Approved Tooling |
| 30 | +================ |
| 31 | + |
| 32 | +| You want the best tools under your belt, for your development lifecycle. |
| 33 | +
|
| 34 | +- `tox`, `poetry`, `ruff`, `mypy`, `pytest`, `black`, `isort`, `mkdocs`, `sphinx` |
| 35 | + |
| 36 | +Template Variant |
| 37 | +================ |
| 38 | + |
| 39 | +You want `poetry`, but what if you want to develop a `pytest plugin`? |
| 40 | + |
| 41 | +- Generate `module`: a Python Distribution, with python API/sdk |
| 42 | + |
| 43 | + - configured with `poetry` backend |
| 44 | +- Generate `module+cli`: a Python Distribution, with a CLI and a python API/sdk |
| 45 | + |
| 46 | + - configured with `poetry` backend |
| 47 | +- Generate `pytest-plugin`: a Python Distribution, designed for a *pytest plugin* |
| 48 | + |
| 49 | + - configured with `setuptools` backend, as Required by `pytest`! |
0 commit comments