All Projects β†’ TezRomacH β†’ Python Package Template

TezRomacH / Python Package Template

Licence: mit
πŸš€ Your next Python package needs a bleeding-edge project structure.

Programming Languages

python
139335 projects - #7 most used programming language

Projects that are alternatives of or similar to Python Package Template

Cookiecutter Lux Python
Cookiecutter template for an idiomatic Python project driven by Makefile
Stars: ✭ 102 (-71.35%)
Mutual labels:  makefile, cookiecutter
Template Python
A template for new Python libraries.
Stars: ✭ 479 (+34.55%)
Mutual labels:  makefile, cookiecutter
Learning Cmake
learning cmake
Stars: ✭ 2,524 (+608.99%)
Mutual labels:  makefile, best-practices
Go Best Practices
Codeship Golang Best Practices
Stars: ✭ 522 (+46.63%)
Mutual labels:  makefile, best-practices
Python Best Practices Cookiecutter
Python best practices project cookiecutter πŸͺ
Stars: ✭ 286 (-19.66%)
Mutual labels:  cookiecutter, best-practices
Theos
A cross-platform suite of tools for building and deploying software for iOS and other platforms.
Stars: ✭ 3,619 (+916.57%)
Mutual labels:  makefile
Ios Handbook
Guidelines and best practices for excellent iOS apps
Stars: ✭ 337 (-5.34%)
Mutual labels:  best-practices
Python Docs Fr
French translation of the Python documentation.
Stars: ✭ 326 (-8.43%)
Mutual labels:  makefile
Facereconstruction
Facial Landmark Detection and head pose compute use dlib, Real time Face Reconstruction use 3D Morphable Face Model fitting
Stars: ✭ 323 (-9.27%)
Mutual labels:  makefile
Http2 Spec
Working copy of the HTTP/2 Specification
Stars: ✭ 3,622 (+917.42%)
Mutual labels:  makefile
Proprietary vendor samsung
Stars: ✭ 342 (-3.93%)
Mutual labels:  makefile
Makefile Templates
Makefile templates for different sized projects
Stars: ✭ 336 (-5.62%)
Mutual labels:  makefile
Spring Jpa Best Practices
spring-jpa best practices
Stars: ✭ 332 (-6.74%)
Mutual labels:  best-practices
Phpthewrongway
A pragmatic view on PHP programming.
Stars: ✭ 338 (-5.06%)
Mutual labels:  makefile
Node.docker
🌐 Super small Node.js container (~15MB) based on Alpine Linux OS
Stars: ✭ 328 (-7.87%)
Mutual labels:  makefile
Intel Nuc Dsdt Patch
Patches and Clover configuration required for Intel NUC5/6/7/8 series mini PCs
Stars: ✭ 355 (-0.28%)
Mutual labels:  makefile
Ports
Public git conversion mirror of OpenBSD's official cvs ports repository. Pull requests not accepted - send diffs to the [emailΒ protected] mailing list.
Stars: ✭ 324 (-8.99%)
Mutual labels:  makefile
Microservices Book
"Microservices Architecture for eCommerce" is an Open Source Book on Microservices and Headless eCommerce. Feel invited to contribute! Read online or download a PDF
Stars: ✭ 337 (-5.34%)
Mutual labels:  best-practices
Awesome Music Production
A curated list of software, services and resources to create and distribute music.
Stars: ✭ 340 (-4.49%)
Mutual labels:  makefile
Xmake
πŸ”₯ A cross-platform build utility based on Lua
Stars: ✭ 4,229 (+1087.92%)
Mutual labels:  makefile

Python Packages Project Generator

Build status Dependencies Status

Code style: black Pre-commit Semantic Versions License

Your next Python package needs a bleeding-edge project structure.

TL;DR

cookiecutter gh:TezRomacH/python-package-template

πŸš€ Features

In this cookiecutter template, we aimed to combine the most state-of-the-art libraries and best development practices for Python.

For your development we've prepared:

For building and deployment:

  • GitHub integration.
  • Makefile for building routines. Everything is already set up for security checks, codestyle checks, code formatting, testing, linting, docker builds, etc. More details at Makefile summary).
  • Dockerfile for your package.
  • Github Actions with predefined build workflow as the default CI/CD.
  • Always up-to-date dependencies with @dependabot (You will only enable it).
  • Automatic drafts of new releases with Release Drafter. It creates a list of changes based on labels in merged Pull Requests. You can see labels (aka categories) in release-drafter.yml. Works perfectly with Semantic Versions specification.

For creating your open source community:

🀯 How to use it

Installation

Before creating a new project from this template, you need to install the dependencies:

pip install -U cookiecutter lice

Go to the directory where you want to create your project and run:

cookiecutter gh:TezRomacH/python-package-template

Input variables

The cookiecutter generator will ask you for some data, you might want to have at hand before generating the project.

The input variables, with their default values (some auto-generated), are:

Parameter Default value Description
project_name python-project The name of the project. It might be a good idea to check the availability of such name before creating the project.
project_description based on the project_name Brief description of your project.
organization based on the project_name Name of the organization. This is needed to generate the license file and to specify the ownership of the project in pyproject.toml.
license MIT Type of license. One of MIT, BSD-3, GNU GPL v3.0 and Apache Software License 2.0.
version 0.1.0 An initial version of the package. Make sure it follows the Semantic Versions specification.
github_name based on the organization GitHub username where the package will be hosted. The cookiecutter will use this name to correctly configure the README.md, pyproject.toml and template files for GitHub.
email based on the organization Email is needed for generating the CODE_OF_CONDUCT.md, SECURITY.md files and to specify the ownership of the project in pyproject.toml.

The entered values will be saved in the cookiecutter-config-file.yml file so that you don't lose them. πŸ˜‰

Demo

Demo

More details

After using this generator, your new project (the directory created) will contain an extensive README.md with instructions for development, deployment, etc. You can pre-read the project README.md template here too.

Initial setting up

Initialize .git, poetry and pre-commit

By running make install

After you run the cookiecutter command and the project appears in your directory, the console will display a message about how to initialize the project.

Package example

All manipulations with dependencies are executed through Poetry. If you're new to it, look through the documentation.

Notes about Poetry

Poetry's commands are very intuitive and easy to learn, like:

  • poetry add numpy
  • poetry run pytest
  • poetry build
  • etc

The template comes with a cute little CLI application example. It uses Typer to CLI and Rich for beautiful formatting in the terminal output.

After installation via make install (preferred) or poetry install you can try to play with the example:

poetry run <project_name> --help
poetry run <project_name> --name Roman

Building and releasing your package

Building a new version of the application contains steps:

  • Bump the version of your package poetry version <version>. You can pass the new version explicitly, or a rule such as major, minor, or patch. For more details, refer to the Semantic Versions standard.
  • Make a commit to GitHub.
  • Create a GitHub release.
  • And... publish πŸ™‚ poetry publish --build

Makefile usage

Makefile contains many functions for fast assembling and convenient work.

1. Download Poetry

make download-poetry
2. Install all dependencies and pre-commit hooks

make install

If you do not want to install pre-commit hooks, run the command with the NO_PRE_COMMIT flag:

make install NO_PRE_COMMIT=1
3. Check the security of your code

make check-safety

This command launches a Poetry and Pip integrity check as well as identifies security issues with Safety and Bandit. By default, the build will not crash if any of the items fail. But you can set STRICT=1 for the entire build, or you can configure strictness for each item separately.

make check-safety STRICT=1

or only for safety:

make check-safety SAFETY_STRICT=1

multiple

make check-safety PIP_STRICT=1 SAFETY_STRICT=1

List of flags for check-safety (can be set to 1 or 0): STRICT, POETRY_STRICT, PIP_STRICT, SAFETY_STRICT, BANDIT_STRICT.

4. Check the codestyle

The command is similar to check-safety but to check the code style, obviously. It uses Black, Darglint, Isort, and Mypy inside.

make check-style

It may also contain the STRICT flag.

make check-style STRICT=1

List of flags for check-style (can be set to 1 or 0): STRICT, BLACK_STRICT, DARGLINT_STRICT, ISORT_STRICT, MYPY_STRICT.

5. Run all the codestyle formaters

Codestyle uses pre-commit hooks, so ensure you've run make install before.

make codestyle
6. Run tests

make test
7. Run all the linters

make lint

the same as:

make test && make check-safety && make check-style

List of flags for lint (can be set to 1 or 0): STRICT, POETRY_STRICT, PIP_STRICT, SAFETY_STRICT, BANDIT_STRICT, BLACK_STRICT, DARGLINT_STRICT, ISORT_STRICT, MYPY_STRICT.

8. Build docker

make docker

which is equivalent to:

make docker VERSION=latest

More information here.

9. Cleanup docker

make clean_docker

or to remove all build

make clean

More information here.

🎯 What's next

Well, that's up to you. I can only recommend the packages and articles that helped me.

Packages:

  • Typer is great for creating CLI applications.
  • Rich makes it easy to add beautiful formatting in the terminal.
  • FastAPI is a type-driven asynchronous web framework.
  • IceCream is a little library for sweet and creamy debugging.
  • Returns makes you function's output meaningful, typed, and safe!
  • Pydantic – data validation and settings management using Python type hinting.

Articles:

πŸ“ˆ Releases

You can see the list of available releases on the GitHub Releases page.

We follow Semantic Versions specification.

We use Release Drafter. As pull requests are merged, a draft release is kept up-to-date listing the changes, ready to publish when you’re ready. With the categories option, you can categorize pull requests in release notes using labels.

For Pull Request we configured this labels:

Label Title in Releases
enhancement, feature πŸš€ Features
bug, refactoring, bugfix, fix πŸ”§ Fixes & Refactoring
build, ci, testing πŸ“¦ Build System & CI/CD
breaking πŸ’₯ Breaking Changes
documentation πŸ“ Documentation
dependencies ⬆️ Dependencies updates

πŸ§ͺ TODOs

This template will continue to develop and follow the bleeding edge new tools and best practices to improve the Python development experience.

Here is a list of things that have yet to be implemented:

  • Add examples of libraries created using this template.
  • Tests coverage reporting (Codecov ?).
  • Builtin integration with Code Climate, Deepsource and CodeFactor (they are free for Open Source).
  • Auto uploading your package to PyPI.
  • Automatic creation and deployment of documentation to GitHub pages (I'm mostly looking at MkDocs with Material Design theme and mkdocstrings).
  • Code metrics with Radon.
  • Docstring coverage with interrogate
  • Dockerfile linting with dockerfilelint.
  • Hall of fame from Sourcerer.
  • Some advanced Python linting (?).
  • Refactor Makefile
  • Help text for all functions in Makefile.
  • Add the option to select the minimum version of Python: 3.7 or 3.8
  • End-to-end testing and validation of the cookiecutter template.

πŸ›‘ License

License

This project is licensed under the terms of the MIT license. See LICENSE for more details.

πŸ… Acknowledgements

This template was inspired by those great articles:

and repositories:

Give them your ⭐️, these resources are amazing! πŸ˜‰

πŸ“ƒ Citation

@misc{python-package-template,
  author = {Roman Tezikov},
  title = {Python Packages Project Generator},
  year = {2020},
  publisher = {GitHub},
  journal = {GitHub repository},
  howpublished = {\url{https://github.com/TezRomacH/python-package-template}}
}
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].