Take bin/fdp back from graphviz, and reach the CLI as python -m fdp

[sammuli]

The problem

graphviz ships bin/fdp — a symlink to dot that dispatches on argv[0] — and so do we. Anything that pulls graphviz into an FDP environment lands a second owner on $PREFIX/bin/fdp, and the CMF provenance stack does exactly that: cmflib -> dvc -> pydot -> graphviz.

Measured on pixi, in a clean env with fdp and cmflib:

bin/fdp -> dot
$ fdp -V
fdp - graphviz version 14.1.2

The FDP CLI isn't shadowed, it's gone — fdp run python ... becomes a graph layout tool. This is what has blocked putting cmflib and toksearch_cmf into the fdp-core metapackage.

It also rules out the obvious mitigation: a deprecation warning is unprintable here, because our entry point is the file that got replaced. The users who need the warning are exactly the ones who can never see it.

The fix

Declare graphviz as our own run dependency. The installer's topological link order puts a dependency before its dependent, so graphviz links first, fdp links last, and we take the file.

Whether that's a fix or insurance depends on the installer, and both are worth having:

• pixi/rattler — graphviz genuinely wins without this; the CLI is broken today. With it we win from scratch (3/3 runs, deterministic), on an incremental pixi add cmflib, and across a real graphviz 13.1.2 → 14.1.2 upgrade. That last case means rattler respects existing file ownership, not merely link order. This is the fdp-install path, so it's where most users are.
• micromamba 2.9.0 — already linked fdp last without this dependency (graphviz at step 1193, fdp at 1266), so it already worked. But nothing enforced that order; it fell out of the solve. This makes it guaranteed instead of lucky.

Nothing is lost on the graphviz side: dot -Kfdp is the documented equivalent of its fdp binary.

Why a test, not just a comment

This relies on installer behaviour that isn't a documented guarantee, so it ships with a guard rather than a comment alone. Since graphviz is now a run dependency, the recipe's own test environment reproduces the collision for free — I confirmed graphviz 14.1.2 is actually present there, so the test isn't vacuous. It fails loudly and names the cause if graphviz ever wins again; if that happens, the answer is to rename the CLI.

The guard also asserts python -m fdp works — the one entry point no other package can take, and the fallback if this ever regresses.

python -m fdp

Second commit adds fdp/__main__.py plus tests, so the CLI is reachable as python -m fdp. Unclobberable by construction, and useful independently of any of the above.

Verification

Check	Result
fdp built with the fix	guard passes; graphviz present in the test env
fdp-core built against released fdp 0.5.1	fails: bin/fdp resolves to: $PREFIX/bin/dot → ERROR: bin/fdp is graphviz's binary
fdp-core built against this branch	passes both outputs: OK: bin/fdp is the FDP CLI alongside cmflib

The negative control does double duty: it proves the guard detects the real failure, and confirms that shipping cmflib in the metapackage with today's released fdp would break the CLI.

Follow-on (not in this PR)

fdp-core has a matching guard and a members.yaml note recording the coupling: its fdp pin must move to whatever release carries this change before cmflib is blessed, or the metapackage ships a broken fdp. So this wants a release once merged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kpkx3jFwQxuBRqoVcw6f27