It doesn't need to be paid though, it's just a result of poor design and poor documentation. It's the only OS where I feel like I'm both 20 years in the future and 20 years in the past.
I think it's also an issue with the flexibility paradox. There isn't a good single way to package Python for Nix because before you even start there are several key questions which come up that most other distros can't even begin reasoning about:
- Are we packaging just one Python package for Nix, or a thing and all its dependencies?
- Is the package already on PyPI, and are we packaging the source from there, or is it the source from some upstream?
- Are any of the dependencies coming from source, either their upstreams or forks?
- For dependencies that already exist in the nixpkgs SHA that is supplying the Python interpreter, do we want to use those versions, or package newer versions? Is it the same decision for everything, or does it vary?
- Is there already a Python level dependency locking scheme in place such as poetry/pipenv/uv, or is it a plain setuptools package? Is it acceptable for Nix to become the locking mechanism, or will that mess things up for non-Nix consumers of this?
- Are we looking to supply a development environment here too, or is this purely about deployment?
To be clear, none of this is an excuse— it's horrifying that there can't be a single "Tool X is the singular Python-on-Nix story, follow the one page tutorial and you're all set". But I think the massive amount of choice and flexibility is the crux of why new methods and tools are still being rapidly invented and proposed.
For myself, I would choose poetry2nix as how I'd ship a Python project to Nix hosts, but that immediately implies some answers to a bunch of the above questions, mandates poetry for your top level project, and once you look closer there turn out to be some truly horrifying implementation details [1] that are what make poetry2nix appear as seamless and friendly as it does.
there is a very real sense in which nix has been riding on a good idea while ergonomics elsewhere in the field have advanced, yes. make no mistake, the technical work, getting programs to behave themselves in a fairly alien environment etc, has been impressive, but it's like in the marathon to get there, the idea of making that process somewhat nicer has been subject to constant procrastination. which sucks since in some sense the lay packager is working with the exact same tools as the people bringing the whole system together. not just nixpkgs dx has fallen down the list of priorities, but technical debt down to nix itself has accrued as well. the tvix effort emerged from dissatisfaction with instability (the same dissatisfaction that kept the actual version of nix used in a typical nixos install well behind master) well before any administrative/sponsorship struggle snuggle, and i still maintain that an effort more conservative in scope such as lix would have emerged politics aside, as again, what the end user sees switching to that is mostly "oh hey this random thing that repeated segfaults conditioned me out of attempting just... works now lol?" or various ux papercuts just ceasing to be. nix-at-large has a ways to go but i am optimistic
atrus|1 year ago
mikepurvis|1 year ago
- Are we packaging just one Python package for Nix, or a thing and all its dependencies?
- Is the package already on PyPI, and are we packaging the source from there, or is it the source from some upstream?
- Are any of the dependencies coming from source, either their upstreams or forks?
- For dependencies that already exist in the nixpkgs SHA that is supplying the Python interpreter, do we want to use those versions, or package newer versions? Is it the same decision for everything, or does it vary?
- Is there already a Python level dependency locking scheme in place such as poetry/pipenv/uv, or is it a plain setuptools package? Is it acceptable for Nix to become the locking mechanism, or will that mess things up for non-Nix consumers of this?
- Are we looking to supply a development environment here too, or is this purely about deployment?
To be clear, none of this is an excuse— it's horrifying that there can't be a single "Tool X is the singular Python-on-Nix story, follow the one page tutorial and you're all set". But I think the massive amount of choice and flexibility is the crux of why new methods and tools are still being rapidly invented and proposed.
For myself, I would choose poetry2nix as how I'd ship a Python project to Nix hosts, but that immediately implies some answers to a bunch of the above questions, mandates poetry for your top level project, and once you look closer there turn out to be some truly horrifying implementation details [1] that are what make poetry2nix appear as seamless and friendly as it does.
[1]: https://github.com/nix-community/poetry2nix/blob/master/over...
0x69420|1 year ago