I won't pretend that working with python in nix is a dream, but most of the complexity you see there is more about the author's "hmm that didn't work let's try this" writing style.
I was also tempted to chronicle my journey, since learning nix is a bit of an undertaking, so I sympathize with the author here, but under the knife of a good editor most of that section would go away.
It's actually quite easy to use nix to install globally whichever version of python you pick at random and then to override that with a specific version of python and specific packages on a per-project basis. Well, for 90% of the packages at least. The other 10% of the time you can either bail and use an imperatively created venv or take the hero's path and add special case code to poetry2nix such that the offending package now works cleanly for everyone.
People often complain about that: you shouldn't have to become a nix package maintainer just to be a nix user. And yeah we'd all like that. But there's something cool about how the line between the two is so thin. I feel like nix has given me many more opportunities to be that hero than I'd have found elsewhere. I don't always take the call, but I have once or twice, and plenty of other people do too. It's something that feels magical about nix. A problem solved somewhere can easily be a problem solved everywhere. The hard part becomes sorting through all the competing solutions.
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?
So many footguns... I get the idea behind a declarative OS like this. But the actual implementation seems to be very lacking. I understand there will always be overhead with new paradigms. But I don't see myself or any of the teams I work with implementing Nix when there is this much overhead to it.
