| 29 Sep 2023 |
 raitobezarius | la plupart des entreprises ou des produits au dessus de nix-shell sont assez mauvais sous le capot technique | 13:47:27 |
| raitobezarius | enfin ça reste utiliser un outil de debuggage de dérivations pour faire des shells de développement | 13:47:46 |
| raitobezarius | donc rien que pour ça, ça fait pas beaucoup de sens de les promouvoir en tant que telle dans l'écosystème ainsi | 13:47:59 |
| raitobezarius | y a des gens qui ont bossé sur la bonne façon de faire, mkMinimalShell, etc. | 13:48:08 |
| raitobezarius | mais je crois pas que ça a atterri quelque part | 13:48:13 |
| raitobezarius | ensuite le pb de devbox et tous les machins avant lui, c'est que ça prend le parti pris de dire qu'avoir un JSON ça capture assez de richesse pour tes environnements | 13:48:56 |
| raitobezarius | mais y a pas tjrs des bonnes façons d'éjecter d'un simple JSON pour ensuite utiliser la puissance complète de Nix | 13:49:15 |
| raitobezarius | ensuite devbox a du support pour des versions spécifiques, y a plein de façons dans l'écosystème de rajouter par dessus nixpkgs, c'est pratique pour du one shot ou des cas simples, mais on réintroduit des versions, donc on a de nouveau les problématiques de version solving, je ne crois pas qu'il y ait de solution à date « propre » (i.e. réintroduire un meta solveur de versions) | 13:50:21 |
| raitobezarius | autre aparté, comme les machins comme devenv, ça tente de fournir des services locaux, et c'est très cool mais c'est pas forcément un truc développé dans nixpkgs du tout vu que le support de services hors de NixOS est chaud à maintenir en général | 13:51:22 |
