Oui, direnv c’est bien, et je trouve direnv avec lorri encore plus chouette (lorri permet de garder les shells en cache, sans garbage collection).

En ce moment pour python j’utilise juste poetry et plus poetry2nix : poetry2nix est sans doute très bien pour faire le packaging à la fin. Mais quand je l’ai testé pour le développement je me retrouvais tout le temps à devoir changer ou ajouter des override du build system. Et quand j’ai besoin de librairie je les rajoute en exportant LD_LIBRARY_PATH. Avec poetry2nix c’est beaucoup plus propre, c’est sûr.

Pour mes projets perso je rajoute un flake.nix (il y a des templates de flake pour rust et python) ou un shell.nix, ça permet de lier l’environnement de développement au projet et ça c’est vraiment chouette.

Au travail, pour éviter de "polluer" les repos, j’ai un flake avec poetry dans un répertoire externe, python bloqué à 3.9, et j’utilise direnv pour l’activer dans tous mes projets. Le problème c’est que l’activation n’est pas instantanée.

Oui, direnv c’est bien, et je trouve direnv avec lorri encore plus chouette (lorri permet de garder les shells en cache, sans garbage collection).

En ce moment pour python j’utilise juste poetry et plus poetry2nix : poetry2nix est sans doute très bien pour faire le packaging à la fin. Mais quand je l’ai testé pour le développement je me retrouvais tout le temps à devoir changer ou ajouter des override du build system. Et quand j’ai besoin de librairie je les rajoute en exportant LD_LIBRARY_PATH. Avec poetry2nix c’est beaucoup plus propre, c’est sûr.

Pour mes projets perso je rajoute un flake.nix (il y a des templates de flake pour rust et python) ou un shell.nix, ça permet de lier l’environnement de développement au projet et ça c’est vraiment chouette, et ça évite d’installer des dépendances système qui ne servent que pour un projet (c++), et d’oublier de les désinstaller.

Au travail, pour éviter de "polluer" les repos, j’ai un flake avec poetry dans un répertoire externe, python bloqué à 3.9, et j’utilise direnv pour l’activer dans tous mes projets. Le problème c’est que l’activation n’est pas instantanée.

Oui, direnv c’est bien, et je trouve direnv avec lorri encore plus chouette (lorri permet de garder les shells en cache, sans garbage collection).

En ce moment pour python j’utilise juste poetry et plus poetry2nix : poetry2nix est sans doute très bien pour faire le packaging à la fin. Mais quand je l’ai testé pour le développement je me retrouvais tout le temps à devoir changer ou ajouter des override du build system. Et quand j’ai besoin de librairie je les rajoute en exportant LD_LIBRARY_PATH. Avec poetry2nix c’est beaucoup plus propre, c’est sûr.

Pour mes projets perso je rajoute un flake.nix (il y a des templates de flake pour rust et python) ou un shell.nix, ça permet de lier l’environnement de développement au projet et ça c’est vraiment chouette, et ça évite d’installer des dépendances système qui ne servent que pour un projet (c++), et d’oublier de les désinstaller.

Au travail, pour éviter de "polluer" les repos, j’ai un flake avec poetry dans un répertoire externe, python bloqué à 3.9, et j’utilise direnv pour l’activer dans tous mes projets. Le problème c’est que l’activation n’est pas instantanée.
Mais après deux ans, je tâtonne encore un peu pour trouver la meilleure manière de faire.

In reply to @julienmalka:matrix.org
Prochain meetup à l'ENS lundi 30 octobre à 19h

Bonjour ici !
Je suis entrain de tenter de faire une config NixOS sous forme de flake commune à toutes mes machines.
Mon objectif ici est de passer par un ensemble de modules custom, et de définir les configs de machines quasi-exclusivement avec les options que ces modules déclarent.
Comme j'ai pas envie de faire de modules spécifiques pour home-manager, et que j'aimerais que l'ensemble des informations pour une machine soit défini dans un seul et unique fichier, cela complique un peu la tâche (même fichier/module importé plusieurs fois pour définir la configuration). J'ai toutefois une jolie erreur quand j'essaie un petit nix flake check qui semble globalement dire qu'il n'arrive pas à récupérer l'option de mes modules custom lors de son ajout dans le paramètre modules de la fonctionnixosSystem.
J'avoue que je me gratte la tête depuis quelques heures (ça m'étonnerait pas que ça soit lié à une erreur débile de ma part).
Comme je n'ai pas d'autres utilisateurs de Nix dans mon entourage, si quelqu'un a quelques minutes à m'accorder pour me filer un coup de main, ça m'aiderait vraiment beaucoup !

Voici le lien du repo: https://git.sr.ht/~dala/nixos-flake-config

Trigger warning: j'ai assez peu d'expérience avec Nix et essaye juste de faire les choses selon la doc et ce que je comprends du code de nixpkgs. Il y a certainement des choses qui vont vous piquer les yeux (je prend vos retours si y'a moyen de faire les choses plus proprement).
Merci d'avance !

le principal, c'est que le concept des modules comme ceci sont des concepts de NixOS et pas du langage Nix:

{
  imports = [ ... ];

  options = ...;
  config = ...;
}

un autre soucis que j'ai vu (mais qui pose pas encore problème), c'est ce bout de code:

  imports = if config.machineType == "workstation"
    then [ ./workstation.nix ] else [ ./server.nix ];