Environnements de développement Nix

Que fait Environnements de développement Nix ?

Créer et maintenir des environnements de développement de projet en utilisant Nix flakes, nixpkgs unstable, devenv et direnv. Garder l'interface publique du flake réduite et placer les détails spécifiques au shell dans des fichiers Nix séparés.

Contrat d'interaction

Traiter la configuration Nix comme une politique de projet exécutable. Ne pas la modifier ni l'activer implicitement.

1. Inspecter le dépôt et expliquer d'abord les modifications proposées.
2. Demander une autorisation explicite avant de créer, modifier, renommer ou supprimer des fichiers. Regrouper les modifications connexes dans une seule demande claire.
3. Une fois les modifications approuvées et terminées, proposer des commandes de validation et demander une autorisation distincte avant d'en exécuter une.
4. Ne pas exécuter direnv allow sans le nommer explicitement et sans avoir reçu l'autorisation. Cela autorise l'évaluation automatique de la configuration du projet.

Si l'utilisateur refuse l'une ou l'autre des autorisations, fournir uniquement le plan ou les commandes et s'arrêter à cette limite.

Valeurs par défaut et périmètre

• Exiger un flake pour tout nouveau travail. Utiliser nixpkgs/nixos-unstable sauf si le projet épingle déjà une révision différente et que l'utilisateur demande de la changer.
• Prendre en charge tous les langages. Ajouter des paquets de langage, des formateurs, des linters, des services et des variables d'environnement uniquement lorsque le projet en a besoin.
• Privilégier nix develop et devShells.<system>.default comme interface portable.
• Utiliser devenv pour ses modules déclaratifs, services, scripts, tests et hooks git lorsque ces fonctionnalités sont nécessaires. Ne pas créer de définitions en double à la fois dans un mkShell brut et dans devenv sans expliquer lequel fait autorité.
• Intégrer direnv via un fichier .envrc versionné uniquement sur demande ou lorsque le projet l'utilise déjà. Préserver les paramètres d'environnement locaux de l'utilisateur.
• Ne jamais remplacer ni supprimer un shell.nix, flake.nix, .envrc, devenv.nix, verrouillage ou configuration CI existant simplement parce qu'une disposition plus récente est préférée.

Inspecter avant de proposer des modifications

Rechercher, au minimum :

• flake.nix, flake.lock, shell.nix, default.nix et le répertoire nix/
• devenv.nix, devenv.yaml et .envrc
• les manifestes et verrouillages de langage, la configuration des formateurs/linters, les lanceurs de tâches et les workflows CI
• la documentation du projet mentionnant les commandes de configuration ou les plateformes prises en charge

Lire les expressions Nix existantes avant de proposer une disposition. Déterminer si le projet a déjà un flake, quels systèmes il prend en charge, comment les dépendances sont épinglées, si devenv est installé ou configuré, et si direnv est intentionnellement exclu.

Lorsqu'une commande est utile pour la découverte, privilégier les commandes en lecture seule comme nix flake metadata ou nix flake show. Demander la permission avant de les exécuter si l'exécution de commandes n'a pas déjà été approuvée par l'utilisateur.

Disposition des fichiers

Pour un dépôt nouveau ou peu configuré, proposer cette disposition sauf si la convention établie du dépôt est meilleure :

.
├── flake.nix
├── flake.lock
├── devenv.nix              # modules et services spécifiques à devenv, lorsqu'ils sont utilisés
├── .envrc                  # point d'entrée direnv, lorsqu'il est utilisé
└── nix/
    └── devshell.nix        # paquets, variables et hooks de shell

flake.nix doit contenir les entrées, la plomberie des systèmes pris en charge et les sorties exportées. Placer les arguments de mkShell, les listes de paquets, les variables d'environnement et les hooks de shell dans nix/devshell.nix. Utiliser d'autres fichiers ciblés sous nix/ lorsque le shell devient important, par exemple nix/packages.nix ou nix/hooks.nix.

Ne pas utiliser shell.nix pour les nouvelles configurations. S'il en existe déjà un, le conserver sauf si l'utilisateur approuve explicitement un plan de migration. Pendant une migration, expliquer les implications de compatibilité pour les utilisateurs qui exécutent encore nix-shell.

Workflow de conception

1. Exposer la situation actuelle

Résumer les fichiers existants pertinents, les outils de projet détectés et les éventuelles incertitudes. Si les exigences sont incomplètes, poser des questions ciblées telles que :

• Quelles plateformes doivent être prises en charge (par exemple, Linux uniquement ou Linux et macOS) ?
• Quelles commandes du projet doivent fonctionner dans le shell ?
• Des services de base de données ou autres services locaux sont-ils nécessaires ?
• devenv doit-il posséder l'environnement, ou doit-il ajouter des fonctionnalités autour d'un devShell ?

2. Proposer une implémentation

Décrire exactement quels fichiers seront ajoutés ou modifiés et pourquoi. Inclure si flake.lock changera, si .envrc sera créé ou modifié, et quelle source possède chaque dépendance.

Pour un nouveau flake polyvalent, utiliser une stratégie explicite des systèmes pris en charge et exposer devShells.<system>.default. Importer l'expression de shell séparée plutôt que de placer tout le corps mkShell dans flake.nix. Garder l'ensemble initial de paquets minimal : ne pas ajouter de chaînes d'outils de langage arbitraires simplement pour que le modèle paraisse complet.

Si l'utilisateur demande devenv, choisir une intégration compatible avec l'installation / la version épinglée de devenv. Conserver les déclarations devenv dans devenv.nix (ou dans des fichiers ciblés qu'il importe). Indiquer clairement si les utilisateurs entrent avec nix develop, devenv shell, ou les deux, et s'assurer que les points d'entrée documentés ne divergent pas silencieusement.

Pour direnv, utiliser la convention existante du projet. Un .envrc basé sur un flake repose généralement sur le support de nix-direnv ; un .envrc basé sur devenv repose sur l'intégration appropriée de devenv. Ne pas écrire un point d'entrée dont l'extension direnv requise n'a pas été identifiée.

Traiter ces éléments comme des faits distincts : si nix-direnv est installé, s'il est intégré au direnv de l'utilisateur, et si le .envrc du projet s'évalue avec succès. Ne pas utiliser direnv stdlib (ou l'absence de use flake dans sa sortie) comme vérification d'installation : cela reflète la bibliothèque standard disponible pour cette invocation et ne fait pas autorité pour une configuration déclarative NixOS ou Home Manager. En particulier, un résultat vide de direnv stdlib | grep -F 'use flake' n'est pas une preuve que nix-direnv est absent.

Lorsque la découverte est approuvée, inspecter les preuves pertinentes sans exagérer ce qu'elles prouvent :

• Sur NixOS ou avec une configuration Home Manager disponible, chercher programs.direnv.enable = true et programs.direnv.nix-direnv.enable = true (ou la configuration de module équivalente). Signaler cela comme une configuration déclarative, pas comme une preuve que le shell actif l'a chargée.
• Vérifier si nix-direnv et direnv sont disponibles dans l'environnement actuel et inspecter le fichier direnvrc applicable ou la configuration générée de direnv lorsqu'elle est accessible. Signaler un exécutable indisponible ou un fichier d'intégration manquant comme une observation de l'environnement actuel, pas une affirmation sur la configuration déclarative de l'utilisateur.
• Lire le .envrc du projet pour identifier son extension requise. Utiliser direnv status pour inspecter son état actuel d'autorisation/chargement. Ne pas déduire qu'un point d'entrée use flake fonctionne tant qu'il n'a pas été évalué dans ce projet.

Uniquement après autorisation explicite, autoriser et tester un .envrc de projet. Préciser que direnv allow modifie l'état de confiance ; le faire suivre de direnv reload ou direnv exec . <commande-inoffensive> pour exercer la configuration. Si l'évaluation ne peut pas être effectuée, dire que l'intégration n'est pas vérifiée plutôt que de déclarer nix-direnv non installé.

3. Obtenir l'autorisation de modification

Utiliser une demande de confirmation concise similaire à :

Je vais ajouter nix/devshell.nix, mettre à jour flake.nix pour exporter le shell de développement par défaut, ajouter/mettre à jour devenv.nix et .envrc, et générer/mettre à jour flake.lock si la résolution des dépendances l'exige. Puis-je effectuer ces modifications ?

Attendre une réponse affirmative. Si le travail proposé diffère du plan approuvé, demander à nouveau avant d'effectuer les modifications supplémentaires.

4. Modifier avec soin

Préserver le formatage et les conventions de nommage locales. Garder les commentaires concentrés sur les contraintes non évidentes plutôt que de reformuler la syntaxe Nix. Épingler les entrées du flake via flake.lock ; ne pas substituer des URL flottantes à un verrouillage.

Lors de l'ajout d'un paquet de shell, privilégier le paquet fourni par le pkgs épinglé du projet. Éviter les paquets non libres, les autorisations de paquets non sécurisés, les caches binaires ou la configuration de substitueurs, sauf si l'utilisateur les demande et les approuve explicitement.

5. Proposer une validation et obtenir une autorisation distincte

Après les modifications, lister uniquement les commandes pertinentes, expliquer leur objectif et demander l'autorisation. Choisir parmi :

nix flake check
nix flake show
nix develop --command <commande-de-vérification-du-projet-ou-de-version-d-outil>
devenv test
devenv shell -- <commande-de-vérification-du-projet-ou-de-version-d-outil>
direnv allow

Utiliser une commande inoffensive pour la vérification d'entrée dans le shell lorsque c'est possible, comme --version d'un outil requis ou le mode de vérification d'un formateur de projet. Expliquer l'accès réseau attendu, les constructions, les téléchargements ou les mises à jour de verrouillage avant les commandes qui pourraient les provoquer. Ne jamais exécuter nix flake update, un garbage collection large, une suppression de magasin ou des commandes modifiant le profil sauf si l'utilisateur le demande explicitement.

6. Rapporter le résultat

Indiquer les fichiers modifiés, la ou les commandes d'entrée, les résultats de validation et toute étape manuelle restante. Par exemple, identifier si l'utilisateur doit exécuter nix develop, devenv shell et/ou direnv allow après avoir examiné .envrc.

Principes de dépannage

• Reproduire et inspecter l'erreur réelle avant de modifier les épingles ou d'ajouter des surcharges.
• Distinguer les échecs d'évaluation, les attributs manquants, les problèmes de support de plateforme, les échecs de construction et les problèmes de dépendances d'exécution.
• Vérifier l'entrée épinglée et l'attribut du paquet avant de supposer qu'un paquet instable existe ou porte le nom attendu.
• Privilégier une correction petite et documentée plutôt que des modifications globales de la configuration Nix.
• Lorsqu'une modification peut affecter la reproductibilité ou tous les contributeurs, présenter des alternatives et demander l'approbation avant de modifier.

Critères d'achèvement

Considérer la tâche comme terminée uniquement lorsque la configuration est modulaire, le point d'entrée déclaré est documenté dans la réponse finale, les vérifications demandées ont soit réussi, soit leur résultat est clairement rapporté, et chaque modification et commande de validation a été précédée de l'autorisation requise.