Outside critique

I think there’s a lot to be said about the Nix 2.0 toolchain - the stuff that’s there is great! The features that are missing are tragic. The fact that we need to fall back to 1.11 tools sometimes leaves me often confused about when I can use nix <something> versus an old tool. (Is there a 2.0 equivalent of nix-env for installs?)

So! I’d love for there to be a clear direction about where Nix-the-tool is going. I think I’ve understood @edolstra’s intention as nix eventually replacing nix-*, right? It seems like contributions there have a lot of value, but I’m honestly not sure how to get started.

One suggestion that came up in follow-on discussion with Dave was the idea of a nix shell-template command - essentially “I’m building a Python project and would like a python shell.nix.” Right now, this is well into the territory of implicit knowledge. I’d frequently go to IRC and ask, and someone has a git repo to show me and… But wouldn’t it be better if in nixpkgs there were a templates/ directory, and a nix tool to wrap around a nix build to produce a working shell.nix for … whatever dev environment you’re trying to set up. (They were trying to get a cabal build going and wound up blowing away their dev boxes in frustration.)

I think the direction another discussion here (Strong opinion: Library packaging - #7 by nyarly) is taking goes to this as well: unifying how Nixpkgs handles outside libraries makes the whole system easier for newcomers to understand, and makes it easier for intermediate users to build mental models of.

I also wonder if the Wiki and blogs ought to be considered antipatterns, to some degree. Clear centralized documentation would do an awful lot to clarify Nix workflows, and the manuals and man pages would seem to be the right places for that.

1 Like