[Nix-dev] Anarchy

[Michael Weiss]

Greetings,

I'd like to derail the discussion about policy and focus on the parts 
about how to reduce the need to agree on policy. As others have pointed 
out, nix is great for having your own cake and I want to know how to 
make the most of it. Unfortunately, I'm incapable of really grasping nix 
as a language and nixpkgs in particular, so all I can do at this point 
is sketch some visions. As Helmut Schimidt said, people with visions 
should go see a doctor and given that many among you have a doctorate 
degree, I think this list is a valid place to turn to.

Packaging software with nix can be easy. Pick a name, point to the 
source, define the dependencies, done. The difficult part is that I'm 
not really done at this point. Ignorant of nix, I then try to find out 
how others have done before me and insert a line in haskell-packages.nix 
and maybe in all-packages.nix, too. This works out until somebody 
upstream adds a package with an adjacent name in the lexicographic 
order, that I chose to respect. Now that's a strange conflict. 
Intuitively, adding something to a collection should never break what's 
already there.

Is it possible to define package names only once by placing the 
expression in the filesystem hierarchy? It would then be impossible to 
have null bytes or slashes in names but I could live with that. Having 
to deal with different hierarchies (attributes, filesystem, a flat 
namespace of names?) and naming restrictions at once is somewhat 
challenging, invites misconfiguration and requires more agreement.

Let's talk about names. The most advanced naming system I know of is 
Content Centric Networking (http://www.ccnx.org/). The basic principle 
is that publishers assign hierarchically structured names to content and 
secure that binding by signing it. Consumers retrieve content by asking 
the network for its name and may optionally specify restrictions on what 
content is acceptable. For example I might ask for enumeration of names 
and subsequently content under ccnx:/nixos.org/pkgs/stdenv signed by 
Eelco and ccnx:/cryp.to/pkgs/haskell signed by Peter or 
ccnx:/InFactWeDon'tRelyOnDNS/home encrypted and signed by me.

The protocol itself does not assign any meaning to names but there are 
naming conventions 
(http://www.ccnx.org/releases/latest/doc/technical/NameConventions.html)
that are useful to follow to get versioning out of the box. It is not to 
be confused with a source control system as it is not concerned with 
merging, just with naming and getting stuff.

Executive summary: Punk works best with pull semantics and preferably 
only one hierarchy.

Cheers,
michi