<Guillaum>
Nazral: si tu es sous nixos, c'est surprenant. Si tu es sur un autre distribution, mais avec des packages utilisant opengl chargés depuis nixpkgs, alors nixGL pourrait être ta solution.
<Guillaum>
alors c'est bizarre. Il y a une difference entre la version de nixpkgs utilisé par ton systeme et la version utilisée par tes applications OpenGL?
<Nazral>
je ne crois pas
<Guillaum>
Quel driver graphique?
<Nazral>
j'ai mis à jour tout en même temps
<Nazral>
alors avant j'en avais pas dans mon configuration.nix, j'ai rajouté mesa au cas ou depuis mais ça n'a rien changé
<Nazral>
j'utilise wayland
<Guillaum>
Je t'avoue ne pas connaitre du tout wayland ;(
mmatthieu has quit [Quit: killed]
Yakulu[m] has quit [Quit: killed]
Nyanloutre[m] has quit [Quit: killed]
Notkea[m] has quit [Quit: killed]
Guest7156 has quit [Quit: killed]
Notkea[m] has joined #nixos-fr
mmatthieu has joined #nixos-fr
Yakulu[m] has joined #nixos-fr
Nyanloutre[m] has joined #nixos-fr
Guest215 has joined #nixos-fr
<eon`>
Nazral: tu utilises quel WM ?
<eon`>
j'ai sway+alacritty sans problème
<eon`>
il me semble que j'avais eu un soucis après une upgrade, j'ai du rebuildé alacritty
luc65r has joined #nixos-fr
teto has joined #nixos-fr
<Nazral>
eon`: sway + alacritty justement :p
<Nazral>
comment as tu rebuild ?
<Nazral>
avec --repair ?
<Nazral>
% nix-env -i --repair alacritty
<Nazral>
error: repairing is not supported when building through the Nix daemon
<Nazral>
j'ai ajouté le setLdLibraryPath parce que c'était conseillé dans le lien que j'ai collé plus haut, mais ça ne marche ni sans ni avec
teto has joined #nixos-fr
luc65r has quit [Ping timeout: 272 seconds]
lsix has quit [Quit: WeeChat 2.7.1]
luc65r has joined #nixos-fr
lsix has joined #nixos-fr
<eon`>
Nazral: simplement via nix-build '<nixpkgs>' -A alacritty
<Nazral>
J'ai alacritty dans mon configuration.nix d'ailleurs, si jamais ça joue
<Nazral>
eon`: ta commande me renvoie juste le path d'alacritty
<eon`>
ca te dit quoi quand tu le lances en fait ?
eoli3n__ has joined #nixos-fr
<Nazral>
[2020-04-14 20:25] [ERROR] Alacritty encountered an unrecoverable error:
<Nazral>
Error creating GL context; Could not create EGL display object
luc65r has quit [Ping timeout: 272 seconds]
luc65r has joined #nixos-fr
jeromelanteri has joined #nixos-fr
luc65r has quit [Ping timeout: 272 seconds]
<jeromelanteri>
J'ai fait une petitye vidéo d'intro sur NixOS, mais comme je suis tout nouveau et que il est probable que je puisse dire des conneries, veuillez me dire si c'est correct ou pas...
<immae>
Je commente au fil de l’écoute : tu peux même lister tout /usr je pense (qui habituellement est plein de dossiers)
<immae>
le terme "isoler" est peut être un peu fort je pense (ça sonne comme "sandbox", or c’est pas le cas)
<immae>
Les hash au début du nom d’une dérivation ne sont pas des md5 je pense (sha256 ?)
<immae>
Il me semble que le fichier hardware-configuration.nix n’est pas "standard" dans /etc/nixos, il est simplement importé depuis /etc/nixos/configuration.nix . Si tu ne l’importes pas depuis ce fichier il sera ignoré comme tout autre fichier
<immae>
Il me semble que les channels sont un reliquat qu’il n’est plus conseillé d’utiliser maintenant, et qu’il vaut mieux utiliser plutôt NIX_PATH à la place
luc65r has joined #nixos-fr
<immae>
Je ne crois pas que nix-env aille chercher quoi que ce soit en ligne, le temps qu’il met est juste pour parser le contenu de ton channel
<jeromelanteri>
immae, ha zut, j'avais lu sur la doc que ce sont des md5sum
<julm>
je n'utilise pas non plus hardware-configuration.nix, pour moi c'est juste nixos-install qui le génère mais rien n'oblige à ça
<jeromelanteri>
seul deux pages dedans sont un plus par rapport à la doc officielle...
<jeromelanteri>
l'idée c'est d'ajouter une description générale qui irait orienter le débutant (comme moi) vers une bonne pratqieu d'administration simple du système. Et donc d'utiliser en premier lieux les commandes "helpers" adéquats.
<jeromelanteri>
si vous avez du temps et que ça vous intéresse, peut être voudriez vous publier sur mon github une liste de ce que je dois modifier dans ma vidéo pour mieux faire.
<jeromelanteri>
et même corriger ma doc .odt...
<immae>
(je continue la vidéo) es-tu sûr que nix va essayer de lire nix.conf dans le répertoire courant ?
<jeromelanteri>
non, je ne suis sûre de rien... je débute avec NixOS.
<immae>
(c’est la première fois que j’entends ça)
<jeromelanteri>
en fait, c'est sur le chan englais qu'on m'a indiqué cela... si j'ai bien compris.
<jeromelanteri>
non, je vais voir ça...apparemment, il y en a plein !
<immae>
je sais que tu peux en mettre un dans /etc/nix/nix.conf hein, juste "dans le dossier courant" j’ai jamais entendu (et ça m’interpelle car ça sonne incorrect)
<julm>
avec export NIX_CONF_DIR=. peut-être
<jeromelanteri>
immae, en fait, j'ai probablement mal compris. Ce que j'ai cru comprendre, c'est que tu pourrais générer ton propre package depuis le répertoire courant que tu as créé et où se trouverait ton application. Dans ce répertoir, il faudrait donc créer ce fichier nix.conf avec les expressions Nix qui vont bien). Mais c'est ce que moi j'ai capté... je suis peut être loin de la réalité.
<julm>
ce serait plutôt un default.nix non ?
<jeromelanteri>
mystère.
<immae>
oui c’est un default.nix dans ce cas qu’il te faut
<immae>
une dérivation en gros
<julm>
"If no paths are specified, then nix-build will use default.nix in the current directory, if it exists."
<immae>
(vidéo finie, je n’ai rien d’autre à ajouter sur le contenu)
<jeromelanteri>
alors, le concept de dérivation aussi.. j'imagine que ça décrit un fichjier qui va orienter vers un autre répertoire de package que le répertoire "maitre" va se servir.
<eon`>
Nazral: tente ptet un nix-build '<nixpkgs>' -A alacritty --check
<jeromelanteri>
julm, ok, donc c'est default.nix dans le rép courant par défaut.
<immae>
jeromelanteri: une dérivation c’est précisément un résultat dans le /nix/store, qui est déterminé à partir d’un script (qu‘on appelle également une dérivation). Ce script est un fichier nix, qui ressemble (même syntaxe) à ce que tu as écrit dans le configuration.nix mais ciblé "build" alors que configuration est ciblé "config"
<jeromelanteri>
julm, dans le lien que tu m'as envoyé, il y a du lourd... je pense que maintenant que j'ai ça sous le coude, va falloir que je regarde tout ça pour essayer de mieux comprendre. Puis de refaire cette vidéo dans la foulée.
<jeromelanteri>
immae, ok, dans la doc du manuel officiel, ils font une distinction entre dérivée et dérivant.
<immae>
hmm
<immae>
en anglais ça donne quoi ?
<immae>
(dérivée vs dérivant)
<jeromelanteri>
et je pensait que du fait du terme employé, il y avait une relation sur la nature du lien qui définit aussi ce qu'est un dérivant et un dérivé... dans le sens où le dérivant est (par analogie) la racine d'appel du dérivé (par exemple, une librairie utilisé par l'application, ou une autre application utile à la'application maitre...
<immae>
Ces deux termes ne m’évoquent rien du tout..
<jeromelanteri>
julm, ok, merci je vais creuser à partir de tout ça.
<immae>
une dérivation peut dépendre d’autres dérivations (aussi bien pour "builder", comme gcc, que au runtime, par exemple la lib openssl)
<immae>
On peut appeler la première dérivée et les dépendances des dérivantes si on veut, mais c’est juste utiliser un nom différent pour le même genre d’objet (une dérivation), je ne sais pas si c’est vraiment utile
<immae>
(dans le sens où openssl est lui-même une dérivation, qui peut dépendre aussi de gcc, etc.)
<jeromelanteri>
immae, lexicalemen,t en français, on aurait plutôt tendance à comprendre que une dérivée est en aval d'un dérivant.
<jeromelanteri>
le dérivant découle du dérivé.
<jeromelanteri>
la dérivée est la résultante appelée par le dérivant.
<jeromelanteri>
non ?
<jeromelanteri>
en fait c'est très confu pour un français, parce que la dérivation, par exemple, c'est l'endroit de la bifurcation, mais ça peut aussi être tout le cheminement de la dérivation. Cependant, on dérive toujours d'autre chose.
<jeromelanteri>
et le dérivant, c'est celui qui créé/prend la dérivation.
<jeromelanteri>
c'est aussi pour tout cela que j'ai vraiment du mal à comprendre les concepts de base.
<jeromelanteri>
Le pire étant de croire avoir compris un truc qu'on à en réalité pas ou mal compris.
<immae>
Alors moi ce que je retiens c’est : une dérivation peut dépendre d’autres dérivations, au moment d’être buildée ou au moment d’être exécutée. Ça s’arrête là :)
<jeromelanteri>
immae, dans ton exemple, donc, gcc est une dérivation de dérivant multiples (dans mon esprit en tout cas à ce jour J).
<immae>
En fait on est en train de discuter sur de la nomenclature, tant que l’idée est correcte c’est pas très important le nom qu’on lui donne
<immae>
Je ne suis juste pas familier avec tes termes c’est tout
<immae>
(mais de toute façon je n’ai jamais essayé de traduire les termes de l’anglais)
<jeromelanteri>
immae, dans le precessus d'apprentissage, le bon usage et la bonne compréhension des mots utilisés dans leur contexte est essentiel.
<jeromelanteri>
c'est aussi la base d'une bonne communication.
<jeromelanteri>
et mon idée, c'est justement de faire un truc qui puisse (au moins pour les français), apporter lexicalement une description à la fois précise mais aussi facile des concepts et du champ lexical de la distribution.
<immae>
Dans ce cas je parlerais de "dérivations" uniquement (tout est dérivation, gcc, zsh, openssl), et de "dépendances"
<immae>
Ce sont des termes suffisamment simples et clairs
<jeromelanteri>
julm, très intéressant, c'est aussi ce que explique Noam Chomsky (un linguiste). Et quand on voyage loin, on fini de se rendre compte que c'est absolument vrai.
<jeromelanteri>
immae, oui mais comment dès lors avec un seul mot ("dérivation") indique tu la hiérarchie de dépendance des liens ?
<julm>
en venant d'une autre distro, je me serais plutôt attendu au terme "package" que "derivation", mais bon..
<jeromelanteri>
il faut donc d'autres mots pour la qualifier...
<immae>
la fermeture (aka closure en anglais)
<jeromelanteri>
julm, oui, je pense que le choix lexical doit êtyre volontaire pour justement montrer que les con,cepts sont très différents.
<immae>
La fermeture d’une dérivation, c’est la dérivation et toutes les dérivations dont elle dépend et récursivement
<jeromelanteri>
(peut être)
<jeromelanteri>
ou alors, dérivation d'ordre 0, do'rdre 1, etc.... mais relativement... une dérivation d'ordre 2 peut aussi être une dérivation d'ordre 0 pour sa dérivée....
<jeromelanteri>
c'est un peu comme avec les "dé&rivée" en math d'ailleurs...
<jeromelanteri>
dérivées
<immae>
si tu veux le terme mathématique on peut parler de graphe orienté acyclique probablement :p
<jeromelanteri>
Esnuite, mon idée n'est pas de changer les mots. Mais bien de pouvoir les traduires au plus proche de ce que les concepteurs ont décidé de leur donner comme sens, et de les décrire le mieux possible dans le but de clarifier tout ça pour... un débutant qui débarque. Je constate que j'ai beaucoup de mal à bien cerner tout le concept.
<immae>
(c’est pas un arbre parce que A peut dépendre de B et C et B peut aussi dépendre de C par exemple)
<immae>
ok
<jeromelanteri>
c'est pas du tout de faire de la procrastination.
<immae>
dans ce cas je suggèrerais dérivation, dépendances et closure. Je suis presque sûr que les termes dérivés et dérivants sont très peu utilisés
<immae>
s/closure/fermeture/
<jeromelanteri>
oui, je suis d'accord, par rapport à ce que je pense comprendre, que dépendance est tout à fait adapté.
<jeromelanteri>
closure => clos (un ensemble clos)
<immae>
closure est un nom alors que clos est un adjectif
<jeromelanteri>
oui
<jeromelanteri>
je ne sais pas si closure en anglais sont bien en rapport avec ces mots: [ enclos, clôture, clos ]
<jeromelanteri>
masi gogol translate parle de "fermeture"
<jeromelanteri>
ce qui, en soi, n'a plus grand chose à voir en fonction du contexte.
<immae>
ça me semble le terme le plus approprié oui au sens mathématique
<jeromelanteri>
oui ok.
<jeromelanteri>
et dans ma doc sur mon github, as tu vu ? N'ai je pas trop écrit de bêtises ?
<julm>
closure ne me choc pas, c'est un terme que nix reprend de la programmation fonctionnelle et des maths
<jeromelanteri>
Bon, en tout cas, vous m'avez fait comprendre que la vidéo est pas top, qu'il y a bien mieux à faire (bon, sur la forme... je ferais pas mieux, je sais pas faire mieux), et que donc va falloir y re-réfléchir et refaire autre chose de plus clair.
<jeromelanteri>
julm, ha voilà...
<immae>
jeromelanteri: les remarques n’avaient pas pour but de descendre ta vidéo hein
<julm>
pour naviguer dans les dépendances tu veux probablement jouer avec nix-store -q --requisites ou nix-store -q --references
<jeromelanteri>
immae, t'inquiète pas, je ne suis pas susceptible et j'apprécie la critique, c'est constructif en plus.
<immae>
Ok
<immae>
> Derivations are typically specified in Nix expressions using the derivation primitive.
<{^_^}>
error: syntax error, unexpected IN, expecting ')', at (string):296:37
<immae>
Il est assez déconseillé d’utiliser (en tant qu’humain) la primitive derivation
<jeromelanteri>
julm, alors oui, pourquoi pas. Le truc c'est, quels sont les premières commandes qu'un débutant doit apprendre ? (surement pas nix...). Un gars sur le chan englais m'a dit: "tu devrais préféré utiliser autre chose que nix-env"...
<jeromelanteri>
immae, hé oui.
<immae>
en tant qu’humain on utilise plutôt mkDerivation par exemple (qui va faire appel à derviation derrière)
<jeromelanteri>
immae, là, tu m'as perdu.
<immae>
quand j’écris une dérivation je vais utiliser stdenv.mkDerivation, qui est un helper qui va transformer mon entrée en un truc qui appelle derivation
<immae>
Il est déconseillé d’utiliser derivation directement
<jeromelanteri>
ha oui, ok
<julm>
jeromelanteri: ben moi j'ai commencé par nix-env car j'étais sous debian pas sous nixos ; sous nixos ce serait nixos-rebuild
<jeromelanteri>
julm, ben j'ai aussi tout commencé par nix-env (et je suis sous archlinux, mais ça m'a paru plus clair d'utiliser nix-env)
<jeromelanteri>
ok, donc (vous me dites si vous avez mieux à faire...) il y a plusieurs concepts en parallèle: les closure, le store, les generation, les profils, les Nix expression, les channel...
<jeromelanteri>
le closure c'est un paquet confiné (le mot est à la mode) dans un store (LE store)
<immae>
hmm
<jeromelanteri>
non ?
<julm>
jeromelanteri: après les commandes t'as vite fait le tour (nix *, nix-shell, nix-collect-garbage, nix-channel) ; le gros morceau je pense que c'est surtout le configuration.nix, savoir chercher les options qui existent soit dans le git de nixpkgs, soit sur https://nixos.org/nixos/options.html
<immae>
Je dirais : le closure c’est une dérivation et toutes ses dépendances
<immae>
(d’ailleurs, uniquement ses dépendances runtime, gcc nes era donc presque jamais dedans)
<jeromelanteri>
immae, donc un ensemble de paquets du store
<immae>
oui
<jeromelanteri>
ok. Et comment lire leurs relations ?
<immae>
julm a donné une commande un peu plus haut
<immae>
nix-store -q --requisites ou nix-store -q --references
<immae>
ça te permet de lister le closure d’une dérivation donnée
<immae>
(runtime toujours je crois bien)
<jeromelanteri>
attends... ça pédale là...
<jeromelanteri>
donc nix-store --requistes te renvoit les dérivée du dessous
<julm>
et tu as les opérations réciproques : --referrers, --referrers-closure et --roots
<jeromelanteri>
nix-store -referenfes celles d'en haut
<julm>
tu peux aussi rajouter --graph
<jeromelanteri>
graph c'est en rapport avec grap de pipenv ?
<jeromelanteri>
ça te renvoit le tout ?
<julm>
man nix-store
<jeromelanteri>
--roots c'est l'origine donc...
<julm>
ça génère un .dot
<julm>
ya --tree aussi
<julm>
je devrait utiliser plus souvent ça tient
<julm>
devrais*
<jeromelanteri>
julm, oui mais man nix-store je l'ai lu, mais si je fais tout ça, c'est justement parce que ça ne me semble pas clair (je ne dis pas quie ça ne lml'ai pas, mais que ça ne l'est pas pour moi... je me dis que d'autres sont au moins aussi con que moi... faut les aider)
<immae>
Je n’utilise quasiment jamais ces commandes je vais avoir du mal à t’aider
<immae>
en général quand j’écris une dérivation je m’intéresse à ses dépendances directes en supposant que celles ci sont bien définies déjà
<jeromelanteri>
immae, pas grave. Peut être les utiliseront nous plus quand ça nous semblera bien plus clair.
<julm>
en effet, nix-store c'est assez avancé comme commande, c'est pas une commande que t'utilises au quotidien
<immae>
Les cas où je pourrais voir le closure serait par exemple si je me rends compte (arrivé récemment) que openssl-1.0.2 est dans le store et que je veux comprendre quelle dérivation s’en sert
<julm>
même quand tu développes des paquets
<jeromelanteri>
bon, je me suis imaginé qu'il y avait une logique dans tout les choix fait par les devs de la ditribution. et partant dfe ce choix de forme de pensée sympa, je mez suis mios en tête de croire que tout ce qui commence par nixos- était un truc plus facile à utilisé (un helper quoi) et qui utilise en interne des commandes qui commencent par nix-...
<julm>
nixos-* c'est quand tu es sous.. nixos
<immae>
nixos- sont quasiment tous des scripts tu as raison sur ce point
<julm>
mais nix n'est pas utilisable que sous nixos
<jeromelanteri>
ha bon...
<jeromelanteri>
nix c'est l'administrateur de paquet.
<julm>
comme je te disais j'ai commencé par toucher à nix en restant sous debian
<jeromelanteri>
et tous les scripts nixos utilisent nix directement, ou indirectement (non ?).
<jeromelanteri>
en fait, nix-* utilisent aussi nix
<jeromelanteri>
ou j'ai tout faut ?
<julm>
en gros mais c'est plus compliqué
<julm>
car par exemple nix-build n'utilise pas nix build
<jeromelanteri>
ce sont des concepts qui, il me semble, ne devraient même pas poser ce genre de problème de réflexion, ça devrait être clair comme de l'eau de roche pas polluée...
<julm>
il y a eu une réécriture et il existe encore en parallèle les deux outils nix-build et nix build
<jeromelanteri>
nix-build n'utilise pas nix build, mais utilise-t-il nix ?
<julm>
nix-build est nix mais dans une ancienne version
<jeromelanteri>
aïe...
<immae>
En gros les nix-* sont voués à disparaître
<immae>
au profit de "nix *"
<jeromelanteri>
ok
<immae>
mais c’est en cours de transition donc les eeux sont présents
<jeromelanteri>
ça vous en êtes sûr à 100% ?
<immae>
En tout cas c’est ce que j’en ai compris
<jeromelanteri>
pour moi c'est un scoop dans ma petite tête.ça remet en cause presque tout ce que je me suis imaginé.
<immae>
et comme nix build évolue mais pas nix-build ça me conforte dans l’idée
<jeromelanteri>
ok
<jeromelanteri>
julm, toi tu vois aussi ça pareil ?
<jeromelanteri>
donc je note ça...
<jeromelanteri>
ok, donc un closure comporte plusieurs packages. Un package est contenu dans nle réperrtoire \/nix\/store
<jeromelanteri>
une dérivation est un lien fort d'une closure (un lien de dépendance descendante)
<jeromelanteri>
un deriver est sont lien montant.
<jeromelanteri>
ok... package pour nixos, c'est toujours package ?
<jeromelanteri>
ok... je prend ça pour un oui.
<immae>
alors hmm
<jeromelanteri>
nix est le package manager, nix-build aussi sous son ancienne version (et est voué à disparaitre).
<jeromelanteri>
immae, ha... j'ai pas bvien capté donc.
<immae>
Je vais essayer de présenter les choses comme je me les représente, dis moi si ça te parle
<jeromelanteri>
merci pour ton temps, c'est sympa.
<immae>
un dossier/fichier dans /nix/store = une dérivation. Cette dérivation peut faire référence à d’autres éléments du store (par exemple un script /nix/store/12345-bla.sh qui contient "/nix/store/abcd-foo" dépendra naturellement de cette dérivation)
<immae>
(c’est moins visible dans un fichier binaire mais c’est pareil)
<immae>
le terme "package" n’est pas vraiment utilisé dans nix. Il peut désigner une "grosse" dérivation (avec plein de dépendances) si on veut vraiment l’utiliser (par opposition à mon simple script /nix/store/12345-bla.sh)
<immae>
ou plus généralement on peut définir un package comme une dérivation qui contient bin share lib (ce qu’on trouve dans /usr)
<immae>
mais ça reste juste une dérivation
<immae>
maintenant une closure de /nix/store/12345-bla.sh c’est /nix/store/12345-bla.sh + /nix/store/abcd-foo + etc. récursivement
<immae>
tout ce qui est nécessaire pour que /nix/store/12345-bla.sh s’exécute correctement
<jeromelanteri>
julm, ok, c'est donc un fait avéré. Mais en même temps: The nix-build command builds the derivations described by the Nix expressions in paths. If the build succeeds, it places a symlink to the result in the current directory. The symlink is called result. If there are multiple Nix expressions, or the Nix expressions evaluate to multiple derivations, multiple sequentially numbered symlinks are created (result, result-2, and
<jeromelanteri>
so on). Semble faire penser que nix et nix-build ne font pourtant pas les mêmes choses. Comme si nix-build servait pour faire des paquets de façon plus locales (où depuis le point de vu d'un dev, faire un paquet), alors que nix administre de façon plus large, n'importe quel paquet. En tout cas, c'est ce que j'avais compris? Ce qui n'empêcherait pas que nix-build disparaisse avec son concept pour laisser la place à nix
<jeromelanteri>
(qui aurait donc une vocation à administrer plus largement).
<immae>
en gros si tu veux envoyer /nix/store/12345-bla.sh à une autre machine, tu dois lui envoyer ses dépendances = sa closure
<jeromelanteri>
immae, y a t il des script .sh dans le nix store ? je n'ai vu que des .drv et des répertoires
<immae>
tu en as très certainement oui
<immae>
tu peux avoir ce que tu veux
<immae>
/nix/store/12345-readme.txt même si tu veux
<immae>
nix s’en fiche, tout ce qu’il veut c’est le script qui permet de générer le fichier/dossier
<jeromelanteri>
immae, ok, donc package serait "derivation" du poin t de vu de nixos. Mais avec quandf même une valeur descriptive un peu différente qu'un paquet sur une autre distro. Ok
<jeromelanteri>
donc la closure, c'est le fichier qui définit les liens entre les dérivations.
<immae>
y’a pas de "fichier"
<julm>
jeromelanteri: nix build fait ce que fait nix-build, c'est juste une autre interface
<jeromelanteri>
julm, ok... vivement qu'elle disparaisse, ça fera du ménage alors.
<immae>
le terme closure désigne juste un concept
<immae>
il n’a pas d’existence réelle dans /nix/store
<jeromelanteri>
immae, un concept ok.
<jeromelanteri>
le concept de closure, ce sont ces liens entre les dérivations
<immae>
les informations sont stockées dans /nix/var/ pour gagner du temps mais c’est tout
<jeromelanteri>
immae, comme un index de closures ?
<immae>
Je ne connais pas bien les détails, mais pour une dérivation donnée, l’index va contenir la liste des dérivations dont il dépend oui
<jeromelanteri>
ok.
<jeromelanteri>
ça semble s'éclaircir.
<jeromelanteri>
alors... next concept... profils et generations
<jeromelanteri>
j'ai vu que dans mon user, j'avais des liens dans .nix-profiles
<immae>
Oui
<jeromelanteri>
des liens symboliques.
<jeromelanteri>
et que donc au fur et à mesure que j'installais des trucs
<immae>
donc là y’a un peu de "magie" :
<jeromelanteri>
un nouveau profil était "généré" (j'en ai donc conclu: une nouvelle génération)
<immae>
quand tu construis un profil, tu va juste prendre une liste de dérivations, et les fusionner enc réant des symlinks
<jeromelanteri>
et que donc, chaque profil réfère à une génération, qui sont en fait, une étape du processus d'installation (mais en fait, si je désinstalle, j'ai un nouveau profil, donc c'est un nouvel état).
<jeromelanteri>
immae, un peu comme un system de versions...
<immae>
si par exemple /nix/store/abcd-firefox/ contient bin/firefox, lib/libfirefox.so, et /nix/store/1234-xterm contient bin/xterm, nix-env va créer une nouvelle dérivation qui contient bin/firefox, bin/xterm et lib/libfirefox.so
<jeromelanteri>
parfait. Et donc quand je switch de profil (nix-env -G <mon_num_de_profil_user>
<immae>
à coup de symlinks dans tous les sens
<jeromelanteri>
je ne vais pas tout re-installé ou désinstaller... mais me remttre au niveau des cursezurs d'index de profils, sur la génération de l'état équivalent
<jeromelanteri>
rien n'est désinstallé...
<immae>
quand tu crées un nouveau profil nix-env crée une nouvelle dérivatoin (sans supprimer l’ancienne)
<immae>
c’est les générations
<jeromelanteri>
question... si je fais un grand coup de ménage (je ne me rappelle plus de la commande, mais y'en a une qui fait le ménage), est ce que ça désinstal aussi ce qui était dans un profil mais qui ne l'est plus dans le profil du moment ?
<immae>
Non
<jeromelanteri>
donc ça voudarit dire que dès que tu as installé un truc, il ne sera jamais plus supprimé, même si tu le désinstall à la prochaine génération ?
<immae>
tes profils sont définis dans /nix/var/nix/... et sont juste des symlinks vers une dérivation de /nix/store
<jeromelanteri>
oui, ça j'ai vu.
<immae>
et le garbage collect ne supprime que ce qui n’est plus cité nulle part
<immae>
donc si tu enlèves le symlink de /nix/var/nix/... l’élément de /nix/store devient dangling et peut être supprimé
<immae>
(ne l’enlèves pas manuellement)
<immae>
nix-env permet de supprimer des générations (ce qui en pratique supprime juste le symlink)
<immae>
Et à partir de là les éléments correspondants du /nix/store pourront être supprimés
<jeromelanteri>
immae, et donc tu peux supprimer une seulke génération intermédiaire.
<jeromelanteri>
puis une fois fait, seulement une fois fait, tu peux supprimer en netoyant.
<immae>
voilà
<jeromelanteri>
ok, compris.
<jeromelanteri>
maintenant, je change de user... celui-ci n'a rien d'autre que les applications système
<immae>
en gros, pour savoir ce qui peut être supprimé de /nix/store, le garbage collect va juste chercher tous les liens qui sont dans /nix/var
<immae>
il va garder tout ça et supprimer le reste et voilà
<jeromelanteri>
j'installe un truc... si ce truc a déjà été installé par un autre user... il ne me le re-install donc plus, il me créé une nouvelle génération avec ce profil qui lie l'appli.
<immae>
oui
<jeromelanteri>
excellente idée.
<jeromelanteri>
et donc, peut être le dernier concept... les canaux (channel)
<jeromelanteri>
est-ce que ce sont les équivalents des repository pour archlinux ?
<immae>
si on veut
<immae>
donc les canaux sont deprecate, mais le concept est assez simple :
<immae>
quand tu installes un channel, ça crée un lien ~/.nix-defexprs/nom_du_channel vers le code donné en lien
<jeromelanteri>
ok
<jeromelanteri>
(avec une étiquette j'ai vu)
<immae>
et ensuite nix-env va cibler nom_du_channel vers ce dossier
<immae>
qui n’est rien d’autre qu’une immense dérivation nix
<jeromelanteri>
ce lien c'est une adresse (un url). Vers un serveur mirroir
<immae>
Du coup avec nom_du_channel.firefox par exemple tu vas pointer vers le firefox dans cette expression
<jeromelanteri>
attends, je suis en pleine côte montante, je transpire là...
<immae>
:D
<jeromelanteri>
bon... donc il y a bien une url ?
<jeromelanteri>
quand tu définis le canal.
<jeromelanteri>
cette url c'est quoi ? un répertoire distant ou un genre d'API ?
<jeromelanteri>
tu tombe où, sur quoi ?
<immae>
ce que tu veux. Souvent c’est un commit git
<jeromelanteri>
ha voilà...
<immae>
Le tout est qu’il contienne un default.nix à la racine
<immae>
tu as des raccourcis j’imagine (par exemple nixos-19.09 va pointer vers le dernier commit de la branche 19.09)
<jeromelanteri>
donc bon, un canal donc c'est une étiquette qui se réfère à une adresse, qui se réfère à un commit distant, qui va faire le lien entre ce que ce comit contient et un index vers une closure (des dérivaations)
<immae>
voilà
<jeromelanteri>
le défault.nix à la racine c'est ce qui dit comment chaque dérivation va être configuré.
<immae>
le default.nix c’est une expression qui va contenir un attrset ("dict" en langage python), chacun pointant vers une dérivation
<immae>
tous les packages de nix sont listés dedans
<jeromelanteri>
alors je me pose aue question. Quand on parle de "la racine", c'est la racine du commit en question ou de là ou tu exécute la commande de nouveau canal ? (en, local), ou ce fameux lieux par défaut ou un chemin indiqué dans la commande ?
<jeromelanteri>
et peut on soit même créé un canal ?
<immae>
oui bien sûr
<immae>
tu pointes vers absolument ce que tu veux
<jeromelanteri>
et configuré comme je veux aussi donc ?
<immae>
Tout à fait
<immae>
ceci dit comme je disais, les canaux sont obsolètes maintenant
<jeromelanteri>
je pourrais, par exemple, tout installé comme j'aime et créer mon canal sur mon github, pour que, si je veux re-installer un NixOS, je puisse utiliser ce canal pour que tout soit remis exactement pareil (niveau logiciel et ses configs, j'entend...) par magie...
<immae>
ah tu mélanges deux choses là :)
<jeromelanteri>
aie
<immae>
le channel va contenir une expression qui résoud en { firefox = une_derivation, xterm = une_autre_derivation, foo = ... } (par exemple)
<immae>
Ensuite nix-env te permet d’aller piocher dans cette expression
<jeromelanteri>
la canal, ça ne peut pas être un ensemble de liens sur toutes ces choses là ? c'est pas un container genre docker...
<immae>
mon_channel.firefox, mon_channel.foo etc.
<jeromelanteri>
ha oui... individuellement donc ?
<immae>
(j’ai pas compris ta question)
<immae>
Oui
<jeromelanteri>
tu peux pas tout grouper dans un channel ?
<immae>
Comment ça ?
<jeromelanteri>
là ça froisse ma logique. Parce que le channel nixos quand tu install... c'est un groupe de dérivations qui est au bout (enfin, des indexs groupés donc)
<immae>
il n’y a aucune dérivation là dedans, juste des expressions
<immae>
qui donneront des dérivations
<jeromelanteri>
oui, justement, je me suis aussi perdu là bas.
<immae>
ton canal ne contient que des recettes en gros
<immae>
pas le gateau
<jeromelanteri>
j'ai vu qu'il y avait une liste de pseudo variables nommées (des expressions)
<immae>
le boulot de nix-env c’est de télécharger le gateau
<jeromelanteri>
oui, pas le contenu de l'application, mais des indexs
<immae>
(télécharger ou fabriquer)
<jeromelanteri>
des index, mais aussi un fichier qui les lient et les configurent.
<immae>
non, des recettes, vraiment. Y’a pas d’index non plus
<immae>
la recette t’explique de quoi tu as besoin pour builder firefox et comment le builder
<jeromelanteri>
nix les téléchargent suivant la liste du canal, et les construit suivant ce fichier de configuration qui lui indiuque les directives. (un PKGBULD en gros)
<immae>
Elle ne te dit pas où le récupérer
<jeromelanteri>
alors comment il le sait ?
<immae>
on a donc notre recette
<immae>
À partir de là, nix calcule un hash
<jeromelanteri>
ok, mais comment nix sait où aller prendre les produits ?
<immae>
(À partir de tous les constituants de la recette)
<jeromelanteri>
dans quel shop ?
<jeromelanteri>
je veux dire, à quelle adresse ?
<immae>
Ensuite il demande à cache.nixos.org "est-ce que tu connais ce hash"
<immae>
si oui, bingo il le télécharge
<immae>
sinon tu es bon pour le builder toi-même (tu as la recette)
<jeromelanteri>
ok, ça je comprends à présent. Mais... il le télécharge où ? Comment sait il où aller faire ses course ?
<immae>
je viens de le dire :p
<immae>
il demande à cache.nixos.org "est-ce que tu connais ce hash"
<jeromelanteri>
je relis
<jeromelanteri>
tout est centralisé là
<jeromelanteri>
à cette unique adresse
<immae>
Par défaut
<jeromelanteri>
c'est une sorte d'adresse centralisée oiù il y a toute les adresse
<jeromelanteri>
s
<jeromelanteri>
par défaut ok.
<immae>
C’est une adresse où tu trouveras toutes les dérivations déjà prébuildées
<immae>
mais rien ne t’oblige à l’utiliser
<immae>
c’est juste pour ggner du temps
<immae>
tu as la recette donc tu peux tout builder toi-même
<immae>
ça va juste prendre un temps fou
<jeromelanteri>
sûr
<jeromelanteri>
ok, ça me sembel aussi plus clair.
<jeromelanteri>
nixpkgs est donc une sotre d'interface pour faire des recettes que nix va appliquées.
<jeromelanteri>
va appliquer
<immae>
nixpkgs c’est une liste de recettes oui
<jeromelanteri>
c'est l'outil qui va te permettre de les faire ?
<immae>
quel outil ?
<jeromelanteri>
je veux dire... ben il faut bien écrire la recette
<jeromelanteri>
et référencer avec des mots clefs que l'on peut voir listé dans le manuel sur nixpkgs. OK
<immae>
Les ingrédients : `buildInputs = [ ncurses pcre ];`
<jeromelanteri>
du coup nixpkgs c'est un peu en python comme un objet qui contient des mots clefs spécifiques avec leurs variables qui font cette recette unique.
<jeromelanteri>
un objet typé quoi...
<immae>
je ne suis pas sûr de comprendre
<jeromelanteri>
c'est un objet typé nixpkggs
<jeromelanteri>
une instance de cet objet plutôt
<jeromelanteri>
nixpkgs a ses méthodes... et son contenu
<jeromelanteri>
c'est un objet instancié quoi...
<jeromelanteri>
c'est le concept dont tu me parles.
<immae>
ok
<jeromelanteri>
(c'est une analogie)
<immae>
c’est pas typé mais oui c’est l’idée
<immae>
(enfin c’est mal typé)
<jeromelanteri>
ok, donc je comprends bien, c'est vraiment top.
<julm>
très mal typé
<NinjaTrappeur>
immae++
<{^_^}>
immae's karma got increased to 12
<jeromelanteri>
julm, quel serait la différence ?
<julm>
immae++
<{^_^}>
immae's karma got increased to 13
<jeromelanteri>
bon, c'est super sympa, j'ai appris énormément.
<jeromelanteri>
NinjaTrappeur, ok, je stock aussi ça dans mes onglets pour NixOS, j'ai énormément de trucs à lire et à voir, mais grâce à immae, tout me semble déjà bien clair, les détails viendront donc plus facilement.
<immae>
oui, la pratique t’aidera
<jeromelanteri>
NinjaTrappeur, opui, la descxription me fait bien penser au concept de Kotlin ou Scala...
<NinjaTrappeur>
C'est assez différent, c'est lazy et pas vraiment typé
<jeromelanteri>
immae, julm NinjaTrappeur merci beaucoup, c'est vraiment sympa d'avoir pris de vôtre temps et d'avoir eu la patience.
<NinjaTrappeur>
pas typé du tout en fait
<immae>
De rien jeromelanteri
<jeromelanteri>
ok, je met ça dans un coin de ma tête pour faire le lien quand je vais m'enfoncer plus dans les détails (sans me noyer)
<immae>
il était broken aux dernières nouvelles dhall-nix non ? ^
<jeromelanteri>
je reviendrais présenter les modifs et la vidéo... bien que il y a peu de vus, ça serait dommage que la vidéo raconte des anneries (et il doit y en avoir quelques unes, c'est certain).
<julm>
où tu écris tu Dhall qui a un meilleur typage, vque tu compiles vers du Nix
<julm>
immae: aucune idée, j'ai jamais testé
<jeromelanteri>
tiens... Haskell c'est un langage que j'essaye d'apprendre en ce moment. Pas facile...
<NinjaTrappeur>
marrant, je ne conaissais pas. Ça marche dans l'autre sens? Ça se fait comment, via une sorte de FFI?
<immae>
jeromelanteri: C’est ce qu’on utilise dans mon boulot
<jeromelanteri>
ben là faut bien comprendre les concepts...
<jeromelanteri>
énormément d'abstractions.
<immae>
(j’ai énormément de mal avec dhall par contre même si j’essaye de m’accrocher de toutes mes forces)
<jeromelanteri>
J'ai jamais autant ramé avec un langage que avec Haskell... ça a l'air super top, mais pfou...
<jeromelanteri>
et alors j'ai regardé le framework web Yesod... bon... c'est pas de mon niveau pour le moment.