Hatch is a productivity tool designed to make your workflow easier and more efficient, while also reducing the number of other tools you need to know. It aims to make the 90% use cases as pleasant as possible.
For me personally, Hatch has entirely replaced the manual (or entire!) use of these:
- Cookiecutter PyPackage
- pip
- virtualenv
- pyenv
- Pew
- inve
- pytest
- Coverage.py
- twine
- bumpversion
- zest.releaser
- Incremental
python setup.py ...
/^\/^\
_|__| O|
\/ /~ \_/ \
\____|__________/ \
\_______ \
`\ \ \
| | \
/ / \
/ / \
/ / \ \
/ / \ \
/ / _----_ \ \
/ / _-~ ~-_ | |
( ( _-~ _--_ ~-_ _/ |
\ ~-____-~ _-~ ~-_ ~-_-~ /
~-_ _-~ ~-_ _-~
~--______-~ ~-___-~
Table of Contents
- Completely cross-platform (terminal colors too!) \(*_^)/
- Configurable project creation, with good defaults
- Easiest virtual environment management available, with support for all shells
- Package management defaults to a per-user basis, allowing global usage with elevated privileges (for your safety)
- Configurable semantic version bumping
- Robust build/package cleanup
- Easy testing with code coverage
- Simple building and releasing for PyPI
- All commands are environment-aware w.r.t. python/pip
Starting a new project is as easy as:
$ hatch new my-app
Created project `my-app`Now you have a fully functional package that can be built and distributed.
$ tree --dirsfirst my-app
my-app
├── my_app
│ └── __init__.py
├── tests
│ └── __init__.py
├── LICENSE-APACHE
├── LICENSE-MIT
├── MANIFEST.in
├── README.rst
├── requirements.txt
├── setup.py
└── tox.ini
2 directories, 8 filesYou can also bump the version of most projects without any setup:
$ git clone -q https://github.com/requests/requests && cd requests
$ hatch grow build
Updated /home/ofek/requests/requests/__version__.py
2.18.4 -> 2.18.4+build.1
$ hatch grow fix
Updated /home/ofek/requests/requests/__version__.py
2.18.4+build.1 -> 2.18.5
$ hatch grow pre
Updated /home/ofek/requests/requests/__version__.py
2.18.5 -> 2.18.5-rc.1
$ hatch grow minor
Updated /home/ofek/requests/requests/__version__.py
2.18.5-rc.1 -> 2.19.0
$ hatch grow major
Updated /home/ofek/requests/requests/__version__.py
2.19.0 -> 3.0.0Checking code coverage is a breeze:
$ git clone https://github.com/ofek/privy && cd privy
$ hatch test -c
========================= test session starts ==========================
platform linux -- Python 3.5.2, pytest-3.2.1, py-1.4.34, pluggy-0.4.0
rootdir: /home/ofek/privy, inifile:
plugins: xdist-1.20.0, mock-1.6.2, httpbin-0.0.7, forked-0.2, cov-2.5.1
collected 10 items
tests/test_privy.py ..........
====================== 10 passed in 4.34 seconds =======================
Tests completed, checking coverage...
Name Stmts Miss Branch BrPart Cover Missing
-----------------------------------------------------------------
privy/__init__.py 1 0 0 0 100%
privy/core.py 30 0 0 0 100%
privy/utils.py 13 0 4 0 100%
tests/__init__.py 0 0 0 0 100%
tests/test_privy.py 57 0 0 0 100%
-----------------------------------------------------------------
TOTAL 101 0 4 0 100%Creating virtual envs is incredibly simple:
$ hatch env my-app
Already using interpreter /usr/bin/python3
Successfully saved virtual env `my-app` to `/home/ofek/.virtualenvs/my-app`.
$ hatch env -ll
Virtual environments found in /home/ofek/.virtualenvs:
my-app ->
Version: 3.5.2
Implementation: CPythonand using them is just as fluid:
$ which python
/usr/bin/python
$ hatch shell my-app
(my-app) $ which python
/home/ofek/.virtualenvs/my-app/bin/pythonKeep reading for so much more!
Hatch is distributed on PyPI as a universal wheel and is available on Linux/macOS and Windows and supports Python 3.5+ and PyPy.
$ pip3 install --user hatchor simply pip if that already points to a Python 3 version.
If hatch doesn't work on your system immediately after that, please
run this command then
that command.
After the first installation, you may want to run hatch config --restore to
ensure your config file is available.
- meta
- next to the snake ascii art, put a
hatched egg (blocks1.0.0)
- next to the snake ascii art, put a
- project creation
- Commands
bench- use https://github.com/ionelmc/pytest-benchmark (blocks1.0.0)python- installs the desired version of Python. will work on each platformstyle- maybe not needed. use https://github.com/PyCQA/flake8docs- maybe not needed. use https://github.com/sphinx-doc/sphinx/
Hatch is distributed under the terms of both
at your option.
- All the people who work on Click
- All the people involved in the Python packaging ecosystem
- All the people involved in the pytest ecosystem
- Ned Batchelder, for his Coverage.py is the unsung heroic tool of the Python community. Without it, users would be exposed to more bugs before we are.
- Te-jé Rodgers for bestowing me the name
hatchon PyPI
Important changes are emphasized.
- Fixed wheel packaging
- Upgrade
userpathdependency - Fixed shipped test suite
adduserpathdependency has claimed/been renameduserpath- Fixed various build errors
- Don't require internet for tests
- Conda can now be installed
on every platform with a simple
hatch conda\[^,^]/ new/initcommands now enter an interactive mode if no project name is specified!
testing now supports the use of a project's dedicated virtual env and any dev requirements can be installed in it automatically!
releasenow allows the use of custom repositories!- Fix:
cleaning now correctly ignores a project's dedicated virtual env. This behavior can be disabled with the new-nd/--no-detectflag.
- Hatch now guarantees Windows support via AppVeyor!
- No project detection will occur if a virtual env is active.
- Virtual envs created with
env,new,init, andshellcommands can now access the system site-packages with the-g/--global-packagesflag! - Improved
setup.pygeneration.
userenamed toshell, though it will remain as an alias!new/initcommands now only emit a warning when there is no config file.- You can now specify what Python to use when creating a virtual env
in the
new/initcommand. - Fix:
useno longer requires the env name argument to be.when targeting a project's dedicated virtual env.
View all history