Pour python, chaque paquet/librairie est installé dans un préfix qui lui est propre. Cependant, nous avons tous les mécanismes en place pour pouvoir composer ces différents paquets.
Une appli packagée (installée sous un préfix qui lui est propre) charge ses dépendances là où elles sont. Pour ça les applis sont patchées à l’installation. Par exemple, voici ce que ça donne pour poezio (seules les premières lignes sont propres à nix, les suivantes viennent de poezio) :
Ça a l’air un peu barbare, mais si on regarde tranquillement, ça nous donne (entre autre*) :
l’interpréteur (exact) à utiliser en première ligne
l’ensemble des chemins où les différentes dépendances se trouvent
Dans les gros avantages à cela, on trouve une réelle facilité à faire co-éxister différents interpréteurs et différentes librairies sans que l’ajout de l’un ou l’autre (ni sa mise à jours d’ailleurs) ne vienne perturber une appli que est installée et qui tourne telle qu’elle est.
Par rapport à un venv « classique » à la python où tu installes toutes tes dépendances dans un même prefix (ce qui peut être fais si vraiment on le souhaite), l’approche nix a l’avantage que les composants sons ré-utilsables d’un contexte à un autre. Qui a déjà du monter, et remonter des venvs avec numpy / scipy comprendra très vite l’intérêt de ne pas avoir à refaire une install (et donc une compilation des modules natifs) des différents composants...
Le second très grand avantage de nix par rapport à un venv se fait sentir quand on ne fais pas que du pure python, mais qu’on va avoir des environnements utilisant des composants non gérés par pip.
* Le script python réel nommé .poezio-wrapped est en fait appelé par un wrapper poezio utilisé pour mettre en place différentes variables d’environnement (dont PATH afin de pouvoir gérer les dépendances éventuelles vers des applis / outils devant être accessible à poezio)
[^] # Re: Python
Posté par lancelotsix . En réponse à la dépêche NixOS, collection printemps‐été 17. Évalué à 2.
Pour python, chaque paquet/librairie est installé dans un préfix qui lui est propre. Cependant, nous avons tous les mécanismes en place pour pouvoir composer ces différents paquets.
Une appli packagée (installée sous un préfix qui lui est propre) charge ses dépendances là où elles sont. Pour ça les applis sont patchées à l’installation. Par exemple, voici ce que ça donne pour
poezio(seules les premières lignes sont propres à nix, les suivantes viennent depoezio) :Ça a l’air un peu barbare, mais si on regarde tranquillement, ça nous donne (entre autre*) :
Dans les gros avantages à cela, on trouve une réelle facilité à faire co-éxister différents interpréteurs et différentes librairies sans que l’ajout de l’un ou l’autre (ni sa mise à jours d’ailleurs) ne vienne perturber une appli que est installée et qui tourne telle qu’elle est.
Par rapport à un venv « classique » à la python où tu installes toutes tes dépendances dans un même prefix (ce qui peut être fais si vraiment on le souhaite), l’approche nix a l’avantage que les composants sons ré-utilsables d’un contexte à un autre. Qui a déjà du monter, et remonter des venvs avec
numpy/scipycomprendra très vite l’intérêt de ne pas avoir à refaire une install (et donc une compilation des modules natifs) des différents composants...Le second très grand avantage de nix par rapport à un venv se fait sentir quand on ne fais pas que du pure python, mais qu’on va avoir des environnements utilisant des composants non gérés par
pip.* Le script python réel nommé
.poezio-wrappedest en fait appelé par un wrapperpoezioutilisé pour mettre en place différentes variables d’environnement (dontPATHafin de pouvoir gérer les dépendances éventuelles vers des applis / outils devant être accessible àpoezio)