Profpatsch/nix-ui.org

## nix-ui.org

      
    Raw
  

              nix-ui.org
            
          
    General

Search paths & namepaces

NIX_PATH only of the form:
  nixpkgs=https://nixos.org…:mypkgs=/home/bar/nixpkgs
then: nix install nixpkgs.pkgs.hello
and nix install mypkgs.pkgs.hello
Alternatively it should be possible to specify the general namespaces of nix
  install, maybe:
# ~/.config/nix/namepspaces.nix:
{ config, ... }:
{
  nix.namespaces.p = nix.namespaces.nixpkgs.pkgs;
}
and now:
  nix install p.hello
nix will create its own namespace module from NIX_PATH first. The above would
  create:
# internal nix namepace module
{ config, ... }:
{
  nix.namespaces = {
    nixpkgs = https://nixos.org…;
    mypkgs = /home/bar/nixpkgs;
  };
}
Terminology

user environment vs profile:
Definitely profile, since user environment would be too specific; profiles
  provide a more general abstraction.
User configuration

nix(os) should also be able to link store paths to user homedir paths. It knows
  (at least for deterministic users) where the homedirs are.
nix tool

attribute name resolution

Two views are clashing here: convenience vs conceptual simplicity

  conceptually simple: full paths of all namepaces have to be given, e.g
    nix install nixpkgs.pkgs.hello
    or with the renamed namespace from above
    nix install p.hello,
    which is already a lot more convenient but still simple.
  

  convenient: an exception for one “special” namespace
    nix install hello
    what is the semantics of that special namespace? Is it simply hardcoded to
      ~”nixpkgs”~ (which would be a very bad solution)
  

Extending the namespace scheme from above I propose a special option,
  nix.namespaces.default, which can be explicitely set. If it is not overwritten
  by the profile’s namepaces module, the nix internal module uses the first
  element in the NIX_PATH:
# internal nix namespace module with default
{ config, ... }:
{
  nix.namespaces = rec {
    default = nixpkgs;
    nixpkgs = https://nixos.org…;
    mypkgs = /home/bar/nixpkgs;
  };
}
nix help

It should be possible to invoke nix help <subcommand> for each subcommand (no
  exceptions).
Whether it should open a manpage, pipe it to $PAGER or just output it to
  stdout is to be discussed. The last option would probably be the cleanest.
nix search

The search by attribute name is not clear to me. How should the syntax be done?
nix install

nix is all about declarativeness and avoiding user-facing state in every way
  possible. I’m therefore in strong favor of making a declarative nix install
  the default; even better, why does nix install do anything different than to
  write to a declarative file? It should only write the package attributes to a
  function that will be instrumented with the current NIX_PATH values on every
  invocation of a nix command.
Examples:
nix install hello
nix install nixpkgs.pkgs.python
generates:
{ namespaces, ... }:
with namespaces;
[ default.hello
  nixpkgs.pkgs.python ]
or similar.
  nix rebuild would then take the path, evaluate the namespaces and fully
  evaluate the profile.
In that light, nix install should probably renamed to nix add and only with
  a rebuild should the profile be changed.
  This also means nix upgrade is unnecessary and nix uninstall is renamed nix
  remove. The example in transactions would then be:
nix remove chromium \; add firefox \; rebuild
Open questions:

  what to do when one package is added twice from different repositories?
  how to handle user defined namespaces in a transparent way?
    e.g. nix add hello with
    namespaces = rec {
  default = p;
  p = config.nix.namespaces.nixpkgs;
}
    
    is okay, but when the user removes p from his namespaces, nix will probably
      throw a pretty awkward error that p is missing in the package file. Maybe a
      hint could be given that it is due to a missing namespace that was still there
      when the package was installed.