fmapx a écrit 3 commentaires

Merci pour le temps passé qu'il a dû falloir pour rédiger cette dépêche.

Pour le reste, ce que je regrette avec Haskell c'est qu'il est plus long et compliqué d'assimiler les multiples extensions de GHC plutôt que le langage en lui-même qui est plutôt agréable.

Ce que je veux dire c'est que c'est pas très rassurant pour industrialiser le dev.

Une autre solution (la dérivation et les overlays sont quand même à privilégier)

nix-env -f https://github.com/NixOS/nixpkgs-channels/archive/nixos-13.10.tar.gz -qaA nodePackages.npm
npm-1.3.11
nix-env -f '<nixpkgs>' -qaA nodePackages.npm
node-npm-4.4.4

Peut-être ne manque-t-il pas un peu plus d'info sur les fichier shell.nix. Pour moi, à condition d'avoir bien compris le default.nix sert à "builder le rendu / binanire … scripts …" alors que le shell.nix sert à créer un environnement de dev temporaire (anciennement les profiles) qui ressemble plus au virtualenv de python.

Exemple d'un petit shell.nix pour utiliser maven, docker-compose et ansible :

with import <nixpkgs> {}; {
  env = stdenv.mkDerivation {
    name = "monprojet";
    buildInputs = [ docker_compose maven python27Packages.ansible ];
  };
}

Avec ce shell.nix, jai la certitude que le dev/sys… qui voudra utiliser le projet pourra le faire avec un simple "nix-shell". Ca donne le role d'un composer de php ou le npm de node mais pour le system.

Autre exemple, un shebang & nix : https://gist.github.com/travisbhartwell/f972aab227306edfcfea

Encore merci pour cette dépêche.