Invoke declares an empty dependencies array and vendors what it needs

One entry point registered under two command names

The console scripts are declared in pyproject.toml and both point at the same callable:

[project.scripts]
invoke = "invoke.main:program.run"
inv = "invoke.main:program.run"

So `invoke` and `inv` are the same program, not a short alias with different behaviour. That matters for muscle memory rather than for capability: a long form for scripts and documentation and a short form for interactive use.

The target is `program.run`, which reads as a module level program object rather than a bare function, so the argument parsing and dispatch live in a module you can also drive yourself. That is the shape you want if you intend to embed Invoke rather than only shell out to it, and it is consistent with the library's stated purpose of organizing executable Python code into CLI-invokable tasks.

The package name on the index is invoke, and the description given in the project metadata is Pythonic task execution. Nothing in the metadata suggests a package you would vendor under a different name to avoid a collision, so if you already have a script or module called invoke in your environment, that is a decision you make rather than one the packaging handles.

The empty dependencies array is annotated, not accidental

This is the line that explains the project more than any prose in the README:

# We have a few 'dependencies' but we vendor them internally.
dependencies = []

The quotation marks around the word dependencies in the comment are doing work. There are third-party libraries involved, and they are copied into the tree rather than resolved at install time, so an installer gets one package with no dependency resolution step.

The trade is straightforward. You get a predictable install on a machine with no network access, and you get the same code version everywhere, since there is no range to drift. What you give up is upstream updates: a vendored library moves when the project decides to move it, not when its author publishes.

For a library whose whole job is running commands on machines you control, that trade is defensible and fairly common. For a library you expect to keep current automatically, it is worth knowing before you add it, because nothing in the metadata will tell you a vendored copy has drifted from upstream.

The build system is declared separately, requiring setuptools 77 or newer with the setuptools.build_meta backend, so the build-time requirement is visible and modern even though the runtime one is empty.

Python 3.9 is the floor and 3.14 is already declared

The version metadata is specific and current. The project declares `requires-python = ">=3.9"`, and the classifier list runs from Python 3.9 through 3.14, with a Python 3 Only marker and no Python 2 classifier anywhere.

The version itself is 3.0.3, which places it after the 3.0 line began. A version 3 release of a library with a long prior history is usually a deliberate reset of the API surface rather than a continuation, so the changelog is the place to find out what moved. The README points at a changelog URL with an empty anchor, which means the anchor is meant to be filled in per version rather than pointing at one fixed page.

The operating system classifiers are worth a look too. POSIX, Unix, MacOS X and Microsoft Windows are all declared, so Windows is a supported target rather than an afterthought, and the environment classifier is Console. The intended audience is Developers and System Administrators, which matches the description of managing shell-oriented subprocesses.

Also declared is a development status of 5, Production/Stable. That is the project's own assessment of itself in its metadata, and it is a claim about the library, not about any particular integration.

If you need Python 3.8 or older, this version of the package does not claim to support it.

The repository dogfoods its own task runner

The top-level listing shows what kind of project this is:

tasks.py
invoke/
tests/
integration/
pytest.ini
pyproject.toml
MANIFEST.in

A tasks.py at the root of a project whose subject is task execution is the clearest evidence available here that the tool is used on itself. Whatever the project needs to do, it does through the interface it publishes.

Around it sit the pieces a maintained Python library carries: pytest.ini for test configuration, MANIFEST.in controlling what goes into a source distribution, a .flake8 configuration, .coveragerc alongside .codecov.yml and a second codecov.yml, and a .circleci directory plus SECURITY.md. The CircleCI badge at the top of the README points at a pipeline for the main branch.

Two directories are named rather than explained. invoke/ is the library package itself. tests/ and integration/ are separate, which suggests unit tests and end-to-end tests are kept apart, and integration tests are usually the slower suite that exercises the installed command line rather than internal functions.

The README does not describe the contents of either directory, so if you want to know how the project tests itself, read them rather than the documentation.

Documentation is three websites, and this README is the shortest one

The README is short by design and it says where the rest is, in three named places.

A high level introduction with example code is on the main project website at pyinvoke.org. Detailed API docs are on a separate versioned site at docs.pyinvoke.org, and the split matters because an unversioned website documents whatever is current while a versioned site lets you pin.

For what changed in a release, there is a changelog page at pyinvoke.org/changelog.html. The README links it with an empty anchor inside the fragment, so the link text points at a versioned position on a page that grows.

There is a fourth resource that is not documentation in the usual sense. The project maintainer keeps a roadmap on his own website at bitprophet.org/projects. The author is named in the project metadata as Jeff Forcier with the same domain as an email address, so the roadmap and the maintenance are the same person rather than a team process.

That is worth knowing before you plan around a feature. A single-maintainer project with a public roadmap gives you visibility into intent and no guarantee about dates.

The API docs and changelog URLs are also declared in the project metadata under project URLs, alongside the source repository, the CI pipeline and the issue tracker.

No GitHub releases, so versions arrive through the package index

The repository publishes no GitHub releases. That changes where version information lives.

The version badges at the top of the README read from the package index rather than from the repository, one for the package version and one for supported Python versions, both targeting the index page for invoke. So the authoritative version is the one published to the index, and the repository is where the source is.

The last push to the repository is dated 2026-04-07.

Practically, this means pinning to a version is the sensible move, and the changelog on the project website is where you find out what a given version changed. If you are reading the source rather than the published package, treat the tree as unreleased until you have checked the version in pyproject.toml against the index.

There is also a SECURITY.md at the root, so vulnerability reporting has a defined path, separate from the issue tracker.

THOUGHTS.rst and sites/ sit beside the code, unexplained

Two root entries have names that invite a guess and carry no explanation. THOUGHTS.rst is a reStructuredText document, so it is prose rather than configuration, and sites/ is a directory whose purpose the README never states.

Given the project hosts its own documentation at two domains, sites/ is plausibly the source of one of them, and a repository that publishes its website from its own tree is a common pattern. That is an inference from the name and the presence of two documentation URLs, not something the README confirms, and the same caution applies to THOUGHTS.rst, which could equally be design notes, a proposal, or an essay kept in the repository for historical reasons.

The rest of the listing is unremarkable and useful as a map: README.rst is the readme rendered from reStructuredText, matching the readme field in the project metadata, LICENSE and pyproject.toml at the root, and .gitignore and .gitattributes for repository hygiene.

The takeaway is narrow but real. This repository holds more than the library package and its tests, and the README is not the place that explains what the extra files are. If you are deciding whether the project is serious about its own documentation, the two hosted sites are the evidence; if you are contributing, THOUGHTS.rst and sites/ are the two files to open first.

Editorial conclusion

Invoke fits a team that wants make and rake style task definitions in Python with subprocess handling included, and that values a library with nothing to resolve at install time. It does not fit someone who wants a general workflow engine with dependency graphs or parallel scheduling, because this README describes a task runner and a subprocess wrapper, not that. Before adopting it, read the API docs at docs.pyinvoke.org rather than this README, which is deliberately short, and note that the repository has no GitHub releases at all, so versions come from the package index and the changelog on the project website.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. Project website
4. pyinvoke/invoke on GitHub
5. README