Vision for nixpkgs

Since nixpkgs is constantly moving, i think a vision describes it best.

I want to propose a vision that is specific enough, so we can work towards a common goal, but broad enough, so everyone approves it.

I want to add this text to the README and the documentation.

The vision we work towards

  • extensive collection of relevant free software packages
  • that are built from source code (and available from our binary cache)
  • are up to date (assisted by automation)
  • and work as expected (ensured by automatic tests)
  • deliver upstream’s original intent (WIP: wording will get improved)
  • with support for linux and macOS (and potentially other platforms like BSD and Windows)
  • unfree software packages are allowed for those who need them

I also propose this as short and precise description:

nixpkgs - extensive collection of free software packages for linux and macOS

This follows the theme that we don’t want to promote unfree software, but also don’t hide it from people who search for it.

What do you think? Any suggestion to improve it?

cc @garbas @edolstra


Nice. Another thing I feel is part of the nixpkgs vision is trying to deliver upstream’s original intent. We try to avoid patching, themeing, etc.


From a marketing perspective, we probably shouldn’t mention “built from source code” without also mentioning our amazing cache.


Thanks for this.

It’s really had me thinking; should nixpkgs be more stringent about excluding artifacts that do not build from release?

While it’s much easier to make that argument for machine-code; I’ve come across a number of derivations for VMs such as Java.

You’ve at least inspired me to fix JRuby’s derivation.

It simply downloads the compiled Java JAR (artifact) rather than building from source.
The ability to easily change to an arbitrary commit and get a different package is one of the fundamental superpowers Nix gives.

I’ve been working on the improvement here. I hope to polish it this week for submission.


I am in support of a passthru or metadata flag to easily identify* whether a derivation is built from true source or not.

Again, this will discount many VM artifacts like: Ruby Gems, Python Eggs, Java JAR’s etc…


As said, i would frame it as vision that everything is built from source, but reality is that it’s sometimes hard. In that case i value to have a (binary) package over no package.

Same with tests. Right now very few packages have tests. It’s not even documented how to create a package test. (i want to change that)

To work on such goals it would be helpful to get a % how many packages are built from source/have tests/… There metadata can help.


You might also want to mention stability through channels :

  • nixos-xx.xx : stable but not bleeding edge and major update every 6 month
  • unstable : more bleeding edge but may be somewhat unstable

I think it is important to show that nixpkgs supports different use cases. For example servers will probably stick to stable releases while power users will probably want the most up to date system even if it means living with a bit of unstability.

I’m not sure how I would word it though without undermining the “up to date” and “work as expected” too much.

@davidak I really like the initiative btw!


I really like the idea to have some precise stat about how much package are build from source or doesn’t depend on precompiled software outside of bootstrap (since I have read all the guix manual a year ago). Will pick some random package, and take a look at how many of them are build from source.


There is an RFC for that: