Modern python env


For a new project I decided to use mach-nix as it seemed to be the easiest solution available (the team is not 100% nix addicts).

Unfortunately, It seems that moder versions of python modules (use setutools-rust, or poetry) which are not supported by mach-nix. In addition, 22.11 channels is no more working (at least for a few cases where we get infinite recursion).

I am not aware of the python build process, and I don’t know how to fix these weird problems.

As the problems are accumulating, I was wondering if mach-nix is still maintained and evolving.

I could have put this question in mach-nix github, but I guess more people could see it here?


1 Like

I found open issues mentioning setuptools_rust (bcrypt 4.0.0 and 4.0.1 missing · Issue #518 · DavHau/mach-nix · GitHub) and the infinite recursion in 22.11 (22.11 # error: infinite recursion encountered ** works on 22.05 · Issue #529 · DavHau/mach-nix · GitHub).

The creator and primary maintainer (@DavHau) is fairly actively working on GitHub - nix-community/dream2nix: Automate reproducible packaging for various language ecosystems [maintainer=@DavHau] recently, and probably just hasn’t had the bandwidth to triage the issues.

I imagine they’d let the community know if they intend to stop maintaining mach-nix (and I imagine they’d be happy to have a few more hands to help manage the support/maintenance load that its success has created…)

1 Like

Yes I also saw the work on dream2nix, unfortunately, it still relies on mach-nix for python, so it doesn’t change anything for me (plus it is quite huge for a mono language project)

I also understand the need for more arms, unfortunately, I am not an expert on pip/python black magic.


Not suggesting dream2nix as an alternative.

But the facts that @davhau is actively developing dream2nix and dream2nix leans on mach-nix for python support both seem like good signals that he doesn’t see mach-nix as a dead project.


Please excuse the lack of communication from my side.
The language2nix story is still a priority for me.
Most of my energy goes into dream2nix these days, as I’m convinced that it is the better way forward.

The goal is to replace mach-nix with dream2nix once the python integration of dream2nix is mature enough.
In the mean time mach-nix won’t get much attention. I’m happy to merge PRs if they come up.

As of now, it is unclear when the dream2nix python integration is going to be finished, as there are a number of other things on my list.

If your company has an interest in speeding this up, please contact me. I know some talented freelance developers who would love to finalize the dream2nix python support if they had the funds for it.

Yes I also saw the work on dream2nix, unfortunately, it still relies on mach-nix for python

dream2nix python does currently not rely on mach-nix, except some database. There are some lessons learned from mach-nix and most of the stuff will likely be re-done.


Not sure if you mean development env or distribution. I find both can be achieved with flake.lock + poetry.lock. The major difference from mach-nix is you have to add code to manage python deps on your own, which is slow to start up a shell than purely dev shell provided by mach-nix.

  description = "reproducible batmobile develpment environment";

  inputs = {
    nixpkgs.url      = "github:nixos/nixpkgs/nixpkgs-unstable";
    flake-utils.url  = "github:numtide/flake-utils";

  outputs = { self, nixpkgs, flake-utils, ... }:
  flake-utils.lib.eachDefaultSystem (system:
      pkgs = import nixpkgs { inherit system; };
      devShell = pkgs.mkShell {
        buildInputs = with pkgs; [
        ++ lib.optionals stdenv.isDarwin [

        shellHook = with pkgs; ''
          source $(poetry env info -p)/bin/activate

          # Nope, it's too slow
          # poetry shell --no-root

Actually, for any language that has a package manager with locking, this approach above is an alternative to a purely nix solution.

1 Like

Thank you for clarifying, I will see how we can work.
Hope dream2nix will be even better than mach-nix.