Invoke: tasks.py over Makefile, subprocesses under Python control
Pythonic task management & command execution.
At a glance
- What is it?
- Invoke is Jeff Forcier's BSD-2-Clause Python library for managing shell-oriented subprocesses and organizing executable Python code into CLI-invokable tasks, drawing on make, rake and Fabric 1.x for its feature set. It vendors its dependencies internally, installs the invoke and inv commands, supports Python 3.9 through 3.14, and is at version 3.0.3 under Production/Stable status.
- Who is it for?
- Use Invoke when a project's operational tasks, builds, deployments, data jobs, should live in Python next to the code they serve rather than in shell scripts or Makefiles, since tasks are ordinary Python functions invokable from the command line with arguments and subprocess handling provided. Choose plain scripts or a task runner native to your stack when the tasks are trivial or non-Python.
- Can I use it commercially?
- Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 175 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Two libraries' worth of inspiration, one API
Invoke is a Python library for managing shell-oriented subprocesses and organizing executable Python code into CLI-invokable tasks, and its lineage is stated openly, drawing inspiration from various sources, make and rake, Fabric 1.x, and others, to arrive at a powerful and clean feature set. The Fabric connection is not incidental, the author is Jeff Forcier, Fabric's maintainer, and Invoke began life as the refactored core of Fabric 1.x, the subprocess and task layer extracted so the remote execution library could build on it. The design goal visible in that history is the separation of concerns, local task execution and process management in one library, remote orchestration in another, with Invoke standing alone for anyone whose tasks never leave the machine.
Zero dependencies, by vendoring
The dependency list in the package metadata is empty, with a comment explaining why, we have a few dependencies but we vendor them internally. That choice has real operational weight, installing Invoke pulls nothing but Invoke, so it cannot conflict with a project's other requirements, and the version resolver never has to reconcile its needs against the host environment's. For a tool that lives in development environments, CI images and system Python installations, that property is quietly decisive, and it explains part of the library's longevity in projects that pin their dependencies tightly. The trade, maintaining vendored copies internally rather than tracking upstream, is the author's to pay, not the user's.
invoke and inv, two entry points
The package installs two console scripts, declared in the project metadata:
[project.scripts]
invoke = "invoke.main:program.run"
inv = "invoke.main:program.run"Both point at the same program runner, so the command name is a typing preference rather than a feature difference, with inv saving four characters on the thousands of invocations a task runner accumulates. The package itself is invoke on PyPI at version 3.0.3, and obtaining it means the Python Package Index, the badge and metadata both pointing there, since the repository ships no installation script of its own. The runnable surface is the whole point of the library, a tasks.py in a project root becomes the command menu, and the runner discovers and dispatches the functions defined there.
Python 3.9 through 3.14, every OS
The classifier list spans Python 3.9 through 3.14, three only, and every desktop operating system, POSIX, Unix, macOS and Microsoft Windows, matching a library whose whole job is running subprocesses on whatever machine the developer is on. The development status is Production/Stable, and the intended audiences are named as developers and system administrators, the two roles that write task files. The build system is setuptools at version 77 or newer, and requires-python is 3.9 or later, the floor of a support matrix that has widened with each Python release, so a task file written years ago runs on a current interpreter without modification, which is the compatibility promise a task runner must keep to stay installed.
A README that is only a table of contents
The repository's README is refreshingly minimal, badges, a welcome paragraph, and pointers. What's new in this version lives in the changelog at pyinvoke.org, the high level introduction including example code lives on the main project website, and the detailed API documentation lives on the versioned docs site at docs.pyinvoke.org. The maintainer keeps a roadmap on his personal website, an unusual transparency about where the project is heading. This structure reflects a documentation philosophy, the repository is for contributors and the website is for users, so nothing in the README pretends to teach the library, and anyone evaluating it follows the links rather than skimming a README that would be obsolete within a release.
The codebase and its own dogfooding
The repository structure shows a library tested like an application, integration and tests directories beside the invoke package, pytest configuration, coverage configuration for Codecov, a CircleCI directory driving continuous integration, and flake8 settings for style. The tell is tasks.py at the repository root, Invoke's own task file using Invoke to run its own development tasks, the dogfooding that keeps the API honest, since the maintainer feels every rough edge of the task runner while maintaining the project. A THOUGHTS.rst file sits beside the README, a design thinking document unusual in a library repository, and sites, security policy and a man page source round out the packaging of a project maintained by one person with strong habits.
No releases, a changelog instead
There are no GitHub releases, and the project's versioning history lives in the changelog page on the website, which the README links with an anchor pattern for each version. The last push landed 2026-04-07, and the version at 3.0.3 reflects a library in mature maintenance rather than rapid development, the roadmap on the maintainer's site carrying the forward plan. For adopters, the practical reading is that Invoke's API is stable across years, the changelog is the authoritative record of what changed between versions, and the GitHub main branch tracks development between PyPI drops, the distribution channel where the badges and metadata agree the current release lives.
Editorial conclusion
Use Invoke when a project's operational tasks, builds, deployments, data jobs, should live in Python next to the code they serve rather than in shell scripts or Makefiles, since tasks are ordinary Python functions invokable from the command line with arguments and subprocess handling provided. Choose plain scripts or a task runner native to your stack when the tasks are trivial or non-Python. Before adopting, read the API documentation at docs.pyinvoke.org since the repository README is only a pointer, check the maintainer's roadmap for direction, and note there are no GitHub releases, with PyPI the distribution channel and version 3.0.3 current.
Frequently asked questions
What is the Python Invoke library?
Invoke is a BSD-2-Clause Python library for managing shell-oriented subprocesses and organizing executable Python code into CLI-invokable tasks, inspired by make, rake and Fabric 1.x. It installs the invoke and inv commands, vendors its dependencies internally so it installs with none, and supports Python 3.9 through 3.14.
How is Invoke related to Fabric?
Invoke draws inspiration from Fabric 1.x and shares its author, Jeff Forcier, and it functions as the local task execution and subprocess layer that the remote-execution-focused Fabric builds upon. Invoke itself handles shell-oriented subprocess management and CLI-invokable tasks without any remote connection features.
Where do you get Invoke and its documentation?
The package is distributed on PyPI under the name invoke, with the current version 3.0.3. Documentation splits across the main project website at pyinvoke.org for introductions and examples, docs.pyinvoke.org for versioned API documentation, and the changelog page for what changed in each version, with the maintainer's roadmap on his own site.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/pyinvoke-invoke)