-
Download .nix file
-
Run:
$ nix run -f all-minecrafts.nix versions.v1_8_9.client -c minecraft -
Enjoy (…power of fixed-output derivations)!
This document contains some ideas for additions to the Nix language.
The Nix package manager, Nixpkgs and NixOS currently have several problems:
- Poor discoverability of package options. Package functions have
function arguments like
enableFoo, but there is no way for the Nix UI to discover them, let alone to provide programmatic ways to
-
nix-channeland~/.nix-defexprare gone. We'll use$NIX_PATH(or user environment specific overrides configured vianix set-path) to look up packages. Since$NIX_PATHsupports URLs nowadays, this removes the need for channels: you can just set$NIX_PATHto e.g.https://nixos.org/channels/nixos-15.09/nixexprs.tar.xzand stay up to date automatically. -
By default, packages are selected by attribute name, rather than the
nameattribute. Thusnix install hellois basically equivalent tonix-env -iA hello. The attribute name is recorded in the user environment manifest and used in upgrades. Thus (at least by default)hellowon't be upgraded tohelloVariant.@vcunat suggested making this an arbitrary Nix expression rather than an attrpath, e.g.
firefox.override { enableFoo = true; }. However, such an expression would not have a key in the user environment, unlike an attrpath. Better to require an explicit flag for this.
TBD: How to deal with search path clashes.
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j