https://github.com/cadeef/cookiecutter-python

Cade's splendiferous python starting point
https://github.com/cadeef/cookiecutter-python

Last synced: 7 days ago
JSON representation

Cade's splendiferous python starting point

• Host: GitHub
• URL: https://github.com/cadeef/cookiecutter-python
• Owner: cadeef
• License: mit
• Created: 2020-10-18T19:37:23.000Z (about 4 years ago)
• Default Branch: main
• Last Pushed: 2024-03-06T04:11:41.000Z (8 months ago)
• Last Synced: 2024-03-06T05:26:13.182Z (8 months ago)
• Language: Python
• Size: 27.3 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# Cade’s Python Cookiecutter (cookiecutter-python)

How I work with python, roughly. Bootstrap projects to eliminate toil.

## Objectives

* Cede formatting control to black, it does a fine job and let’s me focus on code rather than style

* Pytest on push, don’t let me push code that fails tests

* Enforce strict static type analysis via mypy; duck typing is convenient but tracing obscure issues later sucks

* Use flake8 for pattern feedback but ignore style issues (black)

* Use isort for well ordered imports

* Provide templates for common tasks

* Pre-commit works great, always use it

## Install

[Cookiecutter](https://cookiecutter.readthedocs.io) is required to use this cookiecutter template (😉). There are many ways to [install cookiecutter](https://cookiecutter.readthedocs.io/en/1.7.2/installation.html), choose what works best for you. I use [brew](https://brew.sh/) (`brew install cookiecutter`), but it’s not the only way.

## Usage

```

cookiecutter https://github.com/cadeef/cookiecutter-python.git

```

Cookiecutter’s documentation is a bit lackluster (I might jump in to help one of these days); a couple tips for using [personal configuration](https://cookiecutter.readthedocs.io/en/1.7.2/advanced/user_config.html) via `.cookiecutterrc` effectively:

### Default Context

Cookiecutter supports default contexts, as they call them, to provide answers for common questions. Unfortunately, it lacks a specification that suggests expected/reusable variables, so I’ve implemented what makes sense to me. My `.cookiecutterrc` looks kinda like this (email address obscured, but feel free to email me if you’re logged in and can see it):

```yaml

default_context:

  author_name: Jimbob Briggs

  author_email: [email protected]

```

### Abbreviations

Deep in the docs with nary a mention are abbreviations, they make it convenient to select a template without thinking about it. `cookiecutter python` is a lot easier to type than `cookiecutter https://github.com/cadeef/cookiecutter-python.git`. I define it as:

```yaml

abbreviations:

  python: https://github.com/cadeef/cookiecutter-python.git

```

## Contributing

Matter of fact this is personal repo. It doesn’t aspire to best practices, though I try to stick to them, but instead what works for me. My aim is to show my process and possibly help you with yours.

If you’re using it, cool! We probably have similar methodologies and I’d love to hear about it. Raise an issue and let’s talk about it, you may have a great idea that I’d like to integrate into my workflow too.

Fork, make it yours. ❤️

If you are still unconvinced and wish to contribute pull requests, please adhere to common sense guidelines.