Announcing Python on Nix

Long story short:

Create Python environments will all the benefits of Nix
and the best possible user experience. No trade-offs!

pythonOnNix.python39Env {
  name = "example";
  projects = with pythonOnNix.projects; [

All the machinery, hashes, build inputs and runtime dependencies are managed for you under the hood,

So give it a try,
and let me know what you think!


Very interesting, thanks for developing this!

It would be great if you could put this into context. What are the advantages or differences…

  • …to using plain nixpkgs
  • …to using mach-nix
  • …to using poetry2nix

Otherwise, the list of advantages you give is a little confusing, at least for a Nix + Python beginner:

  • “No broken packages” - why are there no broken packages? What packages are broken in nixpkgs and why?
  • “Pure and reproducible” - isn’t that the point of using Nix?
  • “Projects are tested” - what does that mean?

By the way:

@pimiddy Thanks for the feedback! I’ll add a comparison between alternatives soon

Please rename this project as the naming is confusing. As it is now one may think it is tightly connected to Nixpkgs which it is not.


@FRidh Hi,

My only intention is to contribute to the community.

Anyway I’ve renamed it to: GitHub - on-nix/python: Extensive collection of Python projects from PyPI, for Nix!

Though I don’t understand your point, as many projects by many other people also follow the same convention:


And even from the very same nix-community:


I invite you to see it from a different point of view,


1 Like

I don’t think anyone is questioning your good work and clearly good intentions. Thank you for your contributions and for renaming it!

Some of those projects you list probably should also be renamed for the same reason, like nixpkgs-python and nixpkgs-ruby, and nixpkgs-mozilla.

Some of them seem okay to me since they are really tools that directly operate on nixpkgs like nixpkgs-review, nixpkgs-hammering, nixpkgs-monitor, and nixpkgs-update.



From what I understand nixpkgs-mozilla and nixpkgs-stackage have a top-level default.nix file which is an overlay. Thus, are meant to be used as an extension to Nixpkgs.

Others like nixpkgs-python and holo-nixpkgs are wrappers around Nixpkgs, as their default.nix import Nixpkgs. Note, both of these project provide an overlay, but this is not their default goal.

And nixpkgs-ruby is only a flake which defines the expressions for some Ruby interpreters.

What would be your suggested naming schemes?

1 Like

My suggestion would be

X overlay for Nixpkgs

Like the emacs one: GitHub - nix-community/emacs-overlay: Bleeding edge emacs overlay [maintainer=@adisbladis]