Go-Python Toolchain

Python's tooling is written in Python, which is the reason it is as extensible as it is and also the reason it is slow. Type checking a large project, resolving a dependency tree, and packaging an application are all tasks where the work is mostly bookkeeping, and bookkeeping is exactly what a compiled language is good at.

Nobody wanted to rewrite the ecosystem. The useful move was to sit beside it.

Three tools, each its own repository, its own release cadence, and its own package.

pypls is a type checker and language server for Python, written in Go. It runs as a persistent daemon, holding the type graph in memory and reanalysing only what changed, so an editor stays responsive on a large project. It keeps its cache on disk between runs, reports problems one per line with a non zero exit status, and never sends code anywhere. pip install pypls-client.

gopip resolves dependencies. It treats resolution as the constraint satisfaction problem it actually is, solves it in pure Go, and writes a deterministic lock file, then hands the installation itself back to pip. It is validated over a thousand random dependency graphs and resolves the same package sets as the established tools. A repeat resolve of a real project takes about ten milliseconds. pip install gopip-client.

gopack packs an application, a self contained interpreter, and every dependency into one executable that runs on a machine with no Python installed. On first run it extracts what it needs and launches. No container to build, no system packages on the target. Validated by bundling NumPy, Pandas, and FastAPI into runnable binaries. pip install gopack-client.

Each ships a Python launcher that fetches the native binary for the platform on first use, a GitHub Actions setup action, and cross platform releases across Linux, macOS, and Windows on both common architectures. There is a documentation and marketing site over the three.

Three rules hold the design together and each one is a refusal.

Multi repository with zero coupling. Each tool is its own repository, its own module, its own release cadence. No shared library, no monorepo, no cross imports, because the moment they share code they release together and stop being three tools.

The drop in rule. A tool never requires anyone to change their code, their directory layout, or the command they already type.

Sibling, not replacement. Each tool sits beside the existing one and takes the heavy part, rather than claiming to be the new one. The resolver, for instance, resolves and then hands the actual installation back to the standard installer, because being right about a dependency graph and being trusted to install software are different problems.

Creator and lead developer of all three tools and the site.

Caching correctly is the whole game. A warm resolve of a real project drops from seconds to effectively nothing, but only if the cache is provably equivalent to a cold one. That is enforced rather than assumed: the lock file produced from cache, from the live index, and offline must be byte identical on every reference project, checked on every run, alongside a frozen snapshot of the package index so the test suite is not hostage to the network.

Determinism generally. A resolver that returns a different answer on Tuesday is not a resolver, so a three run determinism check gates the whole thing.

Parsing Python from Go, well enough to infer types across a large real world framework, which is the part that has no shortcut.

All four milestones complete and released, followed by a hardening pass driven by benchmarking rather than by intuition. All three tools are published on PyPI and installable today. Free and open source under Apache 2.0, and staying that way.