I love this so much. I dug around a bit and figured out how it works - I have an explanation (with an illustrative diagram) here: https://simonwillison.net/2024/Oct/21/sudoku-in-python-packa...

Figuring out how it works is a great way to learn a bit more about how Python packaging works under the hood. I learned that .whl files contain a METADATA file listing dependency constraints as "Requires-Dist" rules.

I ran a speed comparison too. Using the uv pip resolver it took 0.24s - with the older pip-compile tool it took 17s.

That's why it feels like installing a ML repo is like sudoku. You install everything and at the last step you realize your neural net uses FlashAttention2 which only works on NVIDIA compute version that is not deployed in your cloud VM and you need to start over from scratch.

Here’s the same thing in Poetry (2022): https://www.splitgraph.com/blog/poetry-dependency-resolver-s...

> Solving the versions of python package from your requirements is NP-complete, in the worst case it runs exponentially slow. Sudokus are also NP-complete, which means we can solve sudokus with python packaging.

Is that actually sufficient? Can every system that’s solving something that’s NP-complete solve every other NP-complete problem?

No way pip actually is a really inefficient SAT solver!

This is BRILLIANT ! I knew of a trend to implement lots of different things at compile-time (in Scala and Haskell communities at least) - definitely fun and quirky, but it never seemed that "special". This one, it has an air of old-school computer magic around it, probably because it is so elegant and simple.

See also this 2008 post using Debian package system to solve Sudoku:

https://web.archive.org/web/20160326062818/http://algebraict...

but how does it know the constraints?

This is type of cool hacking I like to see. Kudos! (Or better, Sukodus :) )

How did you even think of that? Nice!

This is a hack.

Now, in MicroLisp, Common Lisp and maybe Emacs' Elisp too:

http://www.ulisp.com/show?33J9