That page seeming depressing is essentially a result of misunderstanding the genre. The point of this blog series is to give a personal, experiential account o

That page seeming depressing is essentially a result of misunderstanding the genre. The point of this blog series is to give a personal, experiential account of exploring the Nix ecosystem through the official docs alone, without seeking any community help or unofficial sources. The title of the blog entry on Python is cheeky in exactly the same wy as the title of the series— the series is not a guide to learning Nix and the post is not a guide to installing Python. As an aside, the biggest pain with Python packaging via Nix in my life right now is the sys.path and sys.base_path issue— python.withPackages (and other Python wrappers, probably) confuse most software into thinking it is think into a virtualenv. This doesn't matter for most software, but Python tools that perform package management operations mistakenly assume it means that the Nix store, where their presumed 'virtualenv' lives, is writable. It's easy to deal with of you have Nix knowledge: just let Nix provide those deps wherever you can. But it's annoying for development where you want some devs on the team to be able to use their tools of choice from the usual Python packaging shitshow (pipx, uv, Poetry, pdm, pip, whatever) freely and naively with a wrapped, Nix-supplied Python interpreter. There are workarounds of course, like just using non-wrapped Python interpeters from Nixpkgs. But it's annoying. There's a fix for all this that made it into Nixpkgs but was then reverted for reasons that seem fixable. I'm thinking about taking up that work but hesitate because I don't have deep Python experience (although I'm using it more and more at work). You have any interest in working on that with me?