The ones you were about to email us.
Do I need a test suite for this to work?
For the rewrites, no. For the behavior check, effectively yes — something has to run your code so PyMolt can watch what it returns. A test suite is the usual way; a script that exercises the main paths works too. Whatever your coverage is, the report shows the share it never observed instead of quietly counting it as passed.
Does my source code leave my machine?
No. A recipe request is a package name and two version strings — that's the whole payload, and it's drawn out in full on this page. No source, no file names, no lockfile, no telemetry. You can also point the CLI at your own server with PYMOLT_ENDPOINT and nothing crosses the boundary at all.
Why is it free? What's the catch?
The catch is the stage: this is v0.1.0 and it needs real codebases more than it needs revenue. The CLI is Apache-2.0 and will stay that way. The hosted hub is free because serving a recipe that already exists costs almost nothing — the expensive part is writing it the first time, and that cost is paid once for everyone.
What does BSL 1.1 on the hub actually mean for me?
The Business Source License lets you read, modify and run the code freely — including inside your company — with one restriction: you may not resell it as a competing hosted codemod service. Each release converts to a fully open licence on a fixed date. It is not OSI-approved open source, which is why the CLI you actually run is Apache-2.0 and the hub is the only part under BSL.
What happens to my workflow if the hub goes away?
Recipes you have already fetched sit in .pymolt_cache and keep replaying offline. Everything except fetching new recipes — scanning, risk, rewriting, the behavior check — is local and has no dependency on us. Commit the cache and your build stays reproducible regardless.
My package isn't in the catalog. Now what?
You still get a mechanical recipe: the hub reads the release diff for your exact version pair and returns the renames and moved imports. What you don't get is behavioral rules, because nobody has written them for that library yet. Search for it on the catalog page — the answer is on screen rather than after an install.
I have five services, not one. Does that work?
scan reports every root it finds, so a monorepo comes back as five roots with five manifests. Everything after that runs one root at a time — you get one report per service, and five services means five runs. Scriptable, but five runs; there is no fleet-wide rollup yet.
What about our internal packages that aren't on PyPI?
scan tags every dependency as pypi, local or unknown, so an internal package is never quietly counted as “nothing to do”. It still gets resolved, risk-scored and behavior-checked — all of that reads your environment, not an index. What it can't get from the public hub is a recipe, because the hub can only diff releases it can see. That is exactly what self-hosting is for: run your own endpoint, publish rules for company-core there, and the CLI resolves public and private the same way.
How long does a run take?
Measured on real repositories: status and scan come back in about 220 ms, of which 210 ms is Python starting up — the analysis itself is 7–20 ms. Mapping the contact surface is the only phase that grows with the codebase: 1.8 s at 8,000 lines, 10.5 s at 33,000. The behavior check is the expensive one, because it has to actually run your code once under each version — budget roughly two runs of whatever exercises it. That is an upgrade-branch job, not a per-commit one.
Will it rewrite my code without asking?
No. Rewrites are a dry run by default and come back as a diff you read first. Applying takes an explicit flag, and anything the tool can't verify is reported rather than applied. It produces findings; you make the call.
What is Axiom, and how does it relate to PyMolt?
PyMolt is the tool you install and run. The Axiom Cloud Hub is the service it asks for migration recipes — the catalog of what changed between two versions of a library. Same project, split in two because one half runs on your machine and the other half is shared infrastructure everyone benefits from.
Is it safe to point at a production codebase?
Run it on a branch, like any refactor. It reads everything and writes nothing until you ask. The honest caveat is the version number: at v0.1.0 you should review the diff rather than trust it, which is exactly why the diff is the default output.
Something not answered here? hi@zeelex.me — a real person reads it.