Journal La galère de Python en déploiement

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
9
23
déc.
2024

Sommaire

Dans un lien récent sur LinuxFR, j'ai défendu la simplicité de mise en oeuvre de Python par rapport à C++…du moins au moins pour un POC, ou un petit script perso. Mais quand on développe un soft un peu plus complexe, eh bien j'avoue que pour ce qui est de tout le reste, autre que le pur développement, Python perd largement de son intérêt. Ou du moins, un bon langage compilé comme C++ , (je préfère, Rust) y gagne.

Un peu d'histoire

Si l'on a vanté la portabilité de C lors de sa sortie, ce n'est pas parce qu'un programme fonctionne tel quel sur n'importe quel OS/Architecture, mais parce qu'il compile a peu près sans changement, sur toute les architectures/OS. A l'époque, on programmait beaucoup en Assembleur ou alors chaque OS avait son propre langage. En C, on avait, et c'est toujours vrai, qu'a recompiler. Et même s'il peut toujours y avoir une dépendance a l'OS (Appels système) ou à l'Architecture (Big-Endian, Little-Endian), sur un OS/Architecture, on a qu'a vérifier les PATH et librairies… et si elles manque, c'est relativement simple à rajouter. On peut même compiler avec les librairies (empaqueter) (Sauf la libC).

Les langages interprétés

Depuis les premier OS, on a eu besoin de pouvoir lancer des programmes sans paser nécéssairement, par l'étape de compilation. Le premier langage interprété "en live" est le Shell (Bash, pour les Linuxien). L'énorme avantage, pour le développeur, c'est qu'il n'y a plus de risque de segfault (Il y a d'autres risque qui y sont du coup exacerbés, mais ce n'est pas le sujet). Cependant, il introduit un problème: c'est que le programme peut être parfaitement correct mais planter si l'interpréteur n'est pas à jour ou même parfois trop récent s'il n'y a pas de rétro-compatibilité. Et ça, c'est un véritable problème a plus d'un niveau pour le déploiement.

Si ce problème existe pour tout les langage interprété, paradoxalement, c'est quand la gestion des dépendance est trop simplifié et que le langage évolue trop qu'il est exacerbé.
Bash étant quasiment immuable (on peut parfois le déplorer), on a rarement des problèmes de ce type (Mais bien d'autres ;) ).
Pour Java, on galère, souvent avec les dépendances, mais somme toute le problème est assez limité. Comme c'est assez complexe d'ajouter des librairies, on en ajoute assez peu…
Pour Python, à contrario, c'est exacerbé. Comme on a des utilitaires comme PIP, on a trop souvent beaucoup de dépendances en cascades. Évidemment, les dépendances évitent de réinventer la roue. Cependant, pour chacune on a des contraintes sur leurs dépendances, voir sur la version du langage. On peut arriver au final a devoir gérer des dépendances complexes entre dépendances.
Les environnement virtuels, permettent simplement d'éviter les conflits avec les autres dépendances installées sur l'OS, mais on garde la même version du langage.

Un cas concret: le miens

Je développe OpenHEMS, un soft en Python, car c'est simple et que je m'appuie sur Home-Assistant et qu'au départ je voulais me contenter d'un script Home-Assistant. Ce soft intègre en dépendance le code-source (Car ce n'est plus complexe autrement) d'Emhass car ce soft intègre une gestion par IA éprouvé des panneaux solaires. Évidemment, j'ai envie de disposer de la dernière version d'Emhass (pour ne pas avoir les bugs, et les meilleurs fonctionnalités). Seulement, il utilise des fonctionnalités Python 3.10 (Je ne sais plus lesquels) et je souhaites le faire tourner sur une carte Open-Hardware (conformément à ma philosophie Open-Source) : Olinuximo. Seulement, OLinuXino ne propose que Debian 11 (C'est maintenu mais pas le dernier) et avec je n'ai que Python 3.9.
Au départ, j'ai pensé recompilé Python sur l'OS et l'embarqué. Cela me permet de gérer comme je veux mes dépendances. Oui mais voilà, ce n'est pas si simple, la compilation a fonctionné, mais je ne disposait pas de toutes les fonctionnalités. J'ai laissé tombé.
J'avais aussi voulu installé Emhass avec pip, mais le problème était plus grave encore, il m'installait une très ancienne version incompatible car elle avait été mal configuré. Et ce même avec Python3.12.

Ma solution : Docker

La manière la plus simple que j'ai trouvé (et sécurisé sans trop pénaliser les performances) c'est d'utiliser Docker. Mais du coup il faut se lancer dans une compilation docker (Avec Github).
Avec Docker OpenHEMS est beaucoup plus simple tester.
C'est aussi vrai que Docker sécurise OpenHEMS. Cela évite qu'une faille OpenHEMS permette de compromettre l'OS. De ce point de vue, c'est même plus sécurisé que de le faire tourner sous un user dédié. Mais cela coupe de tous les passe droits. Quand le logiciel tourne sous docker, il ne dispose pas de tous les accès à l'OS. Or OpenHEMS utilisait certains passe-droits:
1. Il tournait en root, ce qui me permettait de lancer le VPN pour un accès maintenance. Par sécurité (vie privé et autres), je ne veux pas laisser le VPN tourner en permanence. Je veux que l'utilisateur puisse autoriser manuellement la maintenance. J'ai donc utilisé un process root, un "pseudo-cron" qui se lance avec incron quand un fichier est modifié dans un répertoire spécifique.
2. Les logs étaient directement écris dans le /var/log/openhems, il faut un montage (Mais j'ai encore des problèmes là).

En fait, on peut lancer OpenHEMS sur Python 3.9 sans docker, mais on ne disposera pas de l'option Emhass ce qui est bloquant si l'on dispose de panneaux solaires…

PS : Peut-être n'ais-je pas fait les meilleurs choix. Je suis ouvert aux réflexions en commentaires.

En langage compilé

En langage compilé, (Rust j'aimerai), j'aurais certainement codé moins vite, mais j'aurais été plus rapide sur le déploiement. Concrètement, le problème de dépendance est géré à la compilation et on l'oublie trop souvent. Cette galère que j'ai bien connu en C/C++ évite bien des tracas après.
On ne peut pas dire qu'il n'y ait plus du tout de problème de dépendances. Tout le chalenge des distributions est de géré les conflits de version des librairies dynamiques. C'est tout de même minimisé.
En Python, c'est a un tel niveau que les distributions disposent toujours de Python2 en sus de Python3 (Alors que cela date) et que maintenant, on ne peut plus installer de dépendance avec pip (sur Debian du moins). On a accès qu'aux version disponibles et gérées par les mainteneurs de la distribution.

  • # Debian ne pip plus ?

    Posté par  . Évalué à 2 (+2/-3). Dernière modification le 24 décembre 2024 à 01:23.

    on ne peut plus installer de dépendance avec pip (sur Debian du moins). On a accès qu'aux version disponibles et gérées par les mainteneurs de la distribution.

    Je ne savais pas et je suis très étonné, pourquoi donc un tel malheur sur le meilleur OS de l’univers ?

    Le premier langage interprété "en live" est le Shell (Bash, pour les Linuxien).

    Gardons à l’esprit que Bash est d’abord un shell, et non un langage de programmation à proprement parler bien que ce soit le mailleur langage pour programmer, si on veut bien se le dire.

    • [^] # Re: Debian ne pip plus ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+1/-0).

      pourquoi donc un tel malheur sur le meilleur OS de l’univers ?

      Je ne sais pas si tu troll ou si c'est une vrai question mais j'aurais pu préciser. En fait avec pip, suivant les dépendances que tu installes, tu n'a pas toujours les mêmes versions d'installées. Et parfois le mainteneur n'a pas toujours parfaitement testé les dépendances ou les cas. Donc il peut arriver que tu installe une version d'une dépendances qui fasse buguer un programme vital de l'OS. Car beaucoup de script de l'OS sont écris en Python.
      Attention je n'ai pas dit que l'on ne pouvait pas utiliser pip sous Debian. Juste qu'il faut passer par un environnement virtuel.

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

      • [^] # Re: Debian ne pip plus ?

        Posté par  (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 24 décembre 2024 à 09:22.

        Avec pip freeze tu peux avoir les mêmes versions de paquets python à chaque fois (à condition d'avoir réussi une première fois si les dépendances étaient très flottantes). Par contre ça ne garantit pas les autres dépendances pour compiler avec wheel genre gcc et autres (à supposer que ça change le résultat compilé).

        Voir "The Perfect Python Project - Glyph (Nbpy2024)
        https://www.youtube.com/watch?v=kcfERM6fcgU pour rire ou pleurer.

      • [^] # Re: Debian ne pip plus ?

        Posté par  . Évalué à 5 (+3/-0).

        pourquoi donc un tel malheur sur le meilleur OS de l’univers ?

        Je ne sais pas si tu troll

        Oui, il trolle. Sur Alpha du Centaure, ils en ont un bien meilleur, mais ils ne veulent pas nous le passer, ils ont peur qu'on fasse des conneries avec. Ils disent qu'ils pensaient bien faire en nous passant la combine de la roue il y a quatre ou cinq mille ans, mais que vu ce qu'on en a fait depuis, ils ne vont pas faire la même erreur avec le GNU-xr¡ẗṕçē (traduction libre).

        Ils disent aussi que les dauphins se sont mieux débrouillés que nous quand ils leur ont passé le sonar, et que s'ils ont besoin d'un OS un jour, c'est à eux qu'ils le passeront. Ou aux manchots, bien sûr.

    • [^] # Re: Debian ne pip plus ?

      Posté par  (site web personnel) . Évalué à 5 (+3/-0).

      Je crois qu'il fait référence à ce message où par défaut pip t'envoit chier (àmha, à raison) quand tu essayes de l'utiliser en dehors d'un venv 

      $ pip install plotly
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try 'pacman -S
    python-xyz', where xyz is the package you are trying to
    install.

    If you wish to install a non-Arch-packaged Python package,
    create a virtual environment using 'python -m venv path/to/venv'.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.

    If you wish to install a non-Arch packaged Python application,
    it may be easiest to use 'pipx install xyz', which will manage a
    virtual environment for you. Make sure you have python-pipx
    installed via pacman.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

      • [^] # Re: Debian ne pip plus ?

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Et, pour avoir vu qq'un dont certains outils systèmes ne fonctionnaient plus sous sa session, car il avait installé des paquets par pip --user qui prenaient la priorité sur les paquets du système… c'est une bonne chose.

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Debian ne pip plus ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+1/-0).

      Un shell, à partir du moment ou tu peux le scripter (en faire un fichier que tu execute) est un langage de programmation… Bash est donc à ce titre un langage de programmation. Certes il a un rôle particulier mais n'est-ce pas le cas de tout les langages?

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Debian ne pip plus ?

      Posté par  . Évalué à 3 (+1/-0).

      Je ne savais pas et je suis très étonné, pourquoi donc un tel malheur sur le meilleur OS de l’univers ?

      C'est peut-être ps l'OS le problème mais le langage/environnnement utilisé ?

      Bon, oui, le problème c'est peutêtre aussi les distributions qui intègrent trop python au système (tout en connaissant les problèmes que Python génère au niveau des dépendances). Je ne suis pas sûr d'avoir les mêmes problèmes sur un xBSD par exemple.

      Celà dit je me pose quand même quelques questions : je n'ai pas souvenir d'avoir eu les mêmes problèmes avec Perl qui était pas mal intégré dans certaines distributions ou OS. Est-ce parce que je suis passé à côté ? En tout cas pour ma part, dès que je le peux j'évite Python: je préfère passer par Go maintenant pour éviter ce genre de problèmes.

      • [^] # Re: Debian ne pip plus ?

        Posté par  (Mastodon) . Évalué à 4 (+1/-0).

        Python a un peu les même travers que nodejs mais bon ce n'est pas non plus compliqué d'avoir un python pour l'utilisateur, indépendant de celui fourni par la distro.

        J'ignore ce qu'à fait l'auteur de ce journal pour avoir des problèmes avec le python qu'il a compilé (sans doute quelques options ou dépendances oubliées?) mais python se compile très bien sur n'importe quelle distro.

        Par ailleurs mise à part les containers il y a moult manières d'obtenir des binaires python sans se casser la tête. Quelques exemples:
        - des outils de gestion de version de python comme pyenv.
        - nixpkg
        - pkgsrc
        - brew

      • [^] # Re: Debian ne pip plus ?

        Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-0).

        Perl comme Bash évolue très peu et gère "mal" les dépendances. Comme Python facilite la gestion des dépendances, les devs en rajoutent 50 000. Et comme Python veut intégrer tous les trucs super hype, il évolue vite et beaucoup (un peu moins maintenant et plus rétro-compatible depuis le désastre du passage à Python3). C'est de la que viennent les problèmes Python.

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Debian ne pip plus ?

      Posté par  . Évalué à 4 (+2/-0).

      La bonne pratique est de toujours créer un virtualenv pour un projet.
      On utilise pas le profile user et surtout pas le profile du système.

      • [^] # Re: Debian ne pip plus ?

        Posté par  (Mastodon) . Évalué à 3 (+0/-0).

        Bin oui, dès que tu fais un sudo pip install xxx tu rentres en conflit avec d'éventuels apt get install python-xxx (voir avec des paquets yyy qui dont eux-même dépendants d'une autre version de xxx). Debian a simplement le bon goût de t'avertir.

        Le seul paquet réellement indispensable au niveau système c'est venv (ou celui qu'on réfère pour gérer les environnement virtuels), et le reste tu le mettras dans ton environnement virtuel dédié précisément à cette application.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Conda et Pixi

    Posté par  (site web personnel) . Évalué à 1 (+0/-0).

    Sinon tu peux packager ton logiciel sous forme de paquet pip, puis faire un environment avec conda ou pixi.

    Pixi est en Rust, comme UV, il permet de resoudre plus rapidement les dépendances.

    • [^] # Re: Conda et Pixi

      Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-0).

      Mais ça ne résout pas les problèmes de version de Python. Impossible de faire tourner du Python 3.10 sur un Python 3.9.
      Conda et Pixi ou UV sont des environnements virtuel comme venv (avec des différences mineurs). Ah moins que je me trompe?

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

  • # Ah les devs ...

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    Bonjour ami(e)s devs de tout poil

    Et oui tout n'est pas toujours aussi simple dans l'informatique, surtout pour les devs qui veulent faire de l'admin système (l'inverse est aussi vrai :) )

    Quand on veut faire cohabiter plusieurs versions de plusieurs choses sur une machine voici quelques conseils :

    • ne pas travailler avec root : c'est dédié au système
    • si possible chaque "produit" devrait être géré par un utilisateur dédié cela peut devenir contraignant mais aussi très pratique car cela permet d'isoler les problèmes. surtout quand il s'agit d'éditeur ou de dev différent car a un moment ou a un autre les produits vont évoluer différemment mais c'est une méthode destinée au "gros projet"
    • pour des projets moins important un utilisateur suffit, mais différent de root et de votre utilisateur courant

    dans le cas de python (que je connais un peu) :
    - chaque projet devrait avoir son environnement créé avec le module venv et ce n'est pas la peine de le suivre avec git, un venv python c'est jetable et facile à reconstruire, par contre le fichier requirements.txt (pip freeze > requirements.txt) lui doit être suivie avec git

    Et si une version de python précise est nécessaire alors il faut télécharger les sources et le compiler, on trouve plein de scripts sur le net qui simplifie la chose (rech google "python from sources"), ensuite créer un environnement virtuel a partir de cette version

    Python n'est pas pire que les autres, c'est juste qu'il fait partie du système. vous pouvez essayer de changer des librairies C vitales pour le système et vous aurez les mêmes problèmes.

    Un principe de base et de ne pas interférer avec les composants du systèmes, en mode dev "apt install" suffit mais si votre projet prend de l'ampleur, alors il faudra passer par une isolation de chaque composants pour maitriser les différences de versions et une procédure d'installation.

    Après tout dépend du projet mais un projet comme le tien se doit de tenir sur la durée et une solution serait de packager une VM basé sur une debian.

    C'est possible de le coder avec ansible, terraform, fai ou autre. problème cela peut prendre du temps à faire ce genre de choses, même si l'IA peut aider quand on ne connait pas les techniques.

    Docker c'est bien mais comme d'habitude ce n'est pas magique non plus.

    Il existe pléthore de solutions, le problème c'est de trouver la bonne ou plutôt la moins mauvaise. et cela devient de plus en plus difficile de tout connaître et tout évolue très vite.

    Chaque fois que je tombais sur un problème difficile ou en dehors de mon domaine je recherchais comment font les autres …

    Et puis comme on dit chez les shadoks : à chaque problème une solution, si la solution n'existe pas alors c'est qu'il n y a pas de problème :)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.