HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nix-community
poetry2nix
Nix2019–2024
nix-community / poetry2nix

poetry2nix

Convert poetry projects to nix automagically [maintainer=]

14Distinct people
20Mentions
0Explicit recommenders
923GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Convert poetry projects to nix automagically [maintainer=]

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year20 dated mentions

Observed mentions: 2019-12-13 15:55:42 UTC to 2024-12-05 02:34:33 UTC.

02462019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC606

What Hacker News says

20 sources
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, o
Read the rest
r 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...
In Deploying Containers on NixOS: A Guide
poetry2nix has actually been deprecated[1], and is in my experience subtly broken, as is the entire python packaging mechanism in Nix[2]. So we're now getting yet another attempt, this time called pyproject-nix[3]. I'm now considering taking similar stab with common lisp packaging, because the amount of time I lost fighting Nix trying to run a development environment is making me reconsider using Nix at all. [1] https://github.com/nix-community/poetry2nix#:~:text=announce... [2] https://pyproject-nix.github.io/pyproject.nix/build.html [3] https://pyproject-nix.github.io/pyproject.nix
In Deploying Containers on NixOS: A Guide
> As a random example, I googled "packaging python for nix" and the top result [1] is just way too complex for something that should be pretty simple. Aware that this is more of a critique about the documentation situation, as opposed to the python packaging situation. However, there is poetry2nix[1]. Which makes packaging look something like this: myPythonApp = mkPoetryApplication { projectDir = ./.; }; [1](https://github.com/nix-community/poetry2nix)(although it has been merged into nixpkgs master)
In Deploying Containers on NixOS: A Guide
Nix calls them "derivations", but yeah you're right again. Lots of weird language in this space. Specifically, we use this nix project [1] which provides a nice translation layer between a poetry project and a nix derivation. It allows our devs to use poetry where they want (with local relative paths in the pyproject.toml) and ci/cd to have more granular control of deps at build time. There are some corner cases. As you correctly guessed, some more obscure python libraries might require a few extra lines (i.e. to specify that this package needs setuptools etc). of code. 1 - https://github.com/nix-community/poetry2nix
In Rye and Uv: August Is Harvest Season for Python Packaging
It can also make those systems considerably harder to integrate into Nix itself. There almost need to be some language-neutral standards developed for how to manage inputs and lockfiles in such a way that more of this tooling can be shared at the developer/workspace level while also hoisting the same metadata up into systems like Nix and Bazel. As it is, the rust-in-Nix and bazel-in-Nix stories are both pretty terrible, while the Python one is actually not too bad: https://github.com/nix-community/poetry2nix (barring these 4000 lines of horrible hacks: https://github.com/nix-community/poetry2nix/blob/master/over... and these 27000 lines of telling Nix which Python buildsystem every package ever happens to use: https://github.com/nix-community/poetry2nix/blob/master/over...)
In A leadership crisis in the Nix community
I briefly considered it, but there are some big problems: - The new replacement package, syncserver-rs, has already been added to Nixpkgs, along with a NixOS module [0] - Python 2 and the package itself are no longer supported, meaning... - support in Nixpkgs is pretty rough - dependencies have been updated such that they no longer support Python 2, or have been removed outright, meaning... - syncserver has already been removed from Nixpkgs - in order to avoid the problem of unsupported dependencies, I delegated dependency resolution to a community project, poetry2nix[1]. Even so, it was a nightmare to get working, lots of hacks and workarounds were needed Of course, my repo is public, so anyone is welcome to use the Flake within. If they do, I'd suggest dropping me a line so I don't do anything drastic to the package or module. [0] http
Read the rest
In Ask HN: Is anyone successfully self-hosting Firefox Sync?
There are some different/new tools for creating your own Python packages these days. It's still not truly solved in the sense of having a single clear winner , but one of these new package generation tools might serve you better: poetry2nix: https://github.com/nix-community/poetry2nix mach-nix: https://github.com/DavHau/mach-nix dream2nix: https://nix-community.github.io/dream2nix/guides/getting-sta... pynixify: https://github.com/cript0nauta/pynixify pip2nix: https://github.com/nix-community/pip2nix The tools available to you at the time (pypi2nix and maybe python2nix, if it was a long time ago) have been abandoned in favor of the newer tools, I think chiefly poetry2nix but I'm not sure. There's still the Nixpkgs buildPythonPackage stuff, I think, if your goal is to upstream a lib into Nixpkgs. But if you just want to build your own Pyth
Read the rest
on applications and vendorize the deps (e.g., for work), you might try one of the tools above, which weren't available 3+ years ago. dream2nix is by the author of mach-nix IIRC and has the goal of establishing a unified standard and codebase for ${proglang}2nix type package generators. But mach-nix is still maintained and might be the more feature-complete choice between them. Maybe Nix-y Python users and developers can reply with some of their experiences using those tools for real projects :)
In Nix: Taming Unix with Functional Programming
There are multiple ways of doing it. The obvious one (updating nixpkgs) you already mentioned. Second way is to override[1], in documentation they are showing how to change compilation parameters, but you can also use this to change version of dependencies or source tarball for the package. As you use Nix you will eventually need to do it as sometimes package was not updated, or perhaps you need to use older version, or enable compilation option. Third way is to use overlay[2]. In previous way an existing package was modified. Overlay allows to completely replace or add a new one. For example there is a tool called poetry2nix[3], which on the fly translates python poetry lock file to Nix so nix can build them. Nixpkgs includes it and generally is frequently updated, but maybe there was a fix yesterday that hadn't made it there yet and it
Read the rest
fixes an important bug. You can fetch that repo independently and attach it to nixpkgs (or you can use it directly). Nix also has upcoming feature flakes which to my understanding takes this to a new level. So you can easily compose multiple repos like this in your application. > Theres clearly more to Nix than just setting up language environments, which I'm guessing is where its usefuleness really kicks in. But purely for lang env set up, I'm not sure I see a point over other tooling... I use it this way and the killer feature for myself is that for a project all I need to have installed is Nix and I can have exact environment the dev used. It's not mentioned often, but I think a demo of it would be the repo for Nix program[4]. Typically when you want to compile some open source program, after you check out the repo, a hunt starts for the building tools and libraries needed. With nix you just issue build command or enter build shell[5] and things just work with no errors (or at least I did not get them when trying it a while ago. Everything worked on first try). [1] https://nixos.org/manual/nixpkgs/stable/#chap-overrides [2] https://nixos.org/manual/nixpkgs/stable/#chap-overlays [3] https://github.com/nix-community/poetry2nix [4] https://github.com/nixos/nix [5] https://hydra.nixos.org/build/153568733/download/1/manual/co...
In Ditch your version manager
nix-env -i -f '<nixpkgs>' -E 'f: (f {}).python3.withPackages (ps: with ps; [pyyaml requests])' But you don't want to install globally. One of major strengths (for me at least) is that when combined with nix-shell you have something like virtualenv, but for all packages, not just the ones from python. This means that someone else who checks out your project can get the same environment you had for the development. If this is combined with direnv, then you don't even need to invoke nix-shell you just enter the project directory and everything is there. If you use something like poetry2nix[1] it will automatically have the dependencies your project has. [1] https://github.com/nix-community/poetry2nix
In macOS Nix setup: an alternative to Homebrew (2020)
So I haven't used mach-nix, but from what I see it provides its own way of specifying dependencies. While in case of poetry2nix you are using poetry for dependency management and poetry2nix just translates it to Nix. The biggest benefit for using poetry is the dependency resolver which is much smarter than in pip and actually finds packages that match the version requirements (although looks like mach-nix also has a smart resolver. Other benefits are: * nice CLI * ability to package application and upload to PyPI * poetry can still be used by people who don't use Nix Regarding non-python dependencies, this is solved by overrides file[1]. That way most of the time you don't have to think about it. You can also override the override in your project as well. [1] https://github.com/nix-community/poetry2nix/blob/master/over...
In NixOS 21.05
Yes, it's extremely powerful once you truly understand Nix. There are efforts to improve documentation, but it still is lacking (I think the biggest problem is that Nix is so big, not just the OS but it can be utilized as a build system). Just with NixOS is not exactly clear how can you for example build your custom image. I think https://nix.dev/ is approaching the documentation from the right direction. There are also many pieces that people built that you need to find. For example some things that I found accidentally: * https://github.com/nix-community/poetry2nix * https://github.com/matthewbauer/nix-bundle * https://github.com/cleverca22/not-os Unfortunately those side projects often have even worse documentation.
In NixOS 21.05

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.