Journal La galère de Python en déploiement

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
17
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é à 3 (+3/-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é à 4 (+1/-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é à 7 (+5/-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  . Évalué à 3 (+0/-0).

          C’était plus de l’ordre de la boutade que du troll mais oui, je réalise bien que ce n’est pas un propos sérieux. Les propos sérieux ne sont pas ma spécialité, j’y très recours très rarement ;).

          Je disais « de l’Univers » car Debian ne se veut pas une « simple » distribution GNN/Linux, mais un « OS universel », qui vise à faire fonctionner TOUT les ordinateurs, offre la possibilité par exemple d’utiliser le noyau de FreeBSD, et développe même, avec le FSF, un noyau (basé sur un micro noyau et donc, sur le papier, censé être mieux que Linux). C’est à ma connaissance, en tant que distribution GNU/Linux celle qui supporte le plus d’architectures matérielle.

          Le noyau Linux est d’ailleurs lui-même assez « universel », étant donné le nombre d’architectures et de matériel qu’il supporte (du gadget connecté au super-calculateur…), à ma connaissance (relativement limitée), aucun autre noyaux type *NIX commercial n’était jamais arrivé à ça.

          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.

          si un interfaçage direct entre cerveau et machine est disponible je suis d’accord qu’on le réserve en priorité aux dauphins ! Sans aucun doute. ^^

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

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

            offre la possibilité par exemple d’utiliser le noyau de FreeBSD

            Ce qu’offre aussi bien évidemment le système FreeBSD lui-même (je préfère préciser).

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

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

            Le noyau Linux est d’ailleurs lui-même assez « universel », étant donné le nombre d’architectures et de matériel qu’il supporte (du gadget connecté au super-calculateur…), à ma connaissance (relativement limitée), aucun autre noyaux type *NIX commercial n’était jamais arrivé à ça.

            NetBSD peut être ?
            Je préfère préciser comme tu l'as fait pour pkg-ng

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

        Posté par  . Évalué à 6 (+3/-0). Dernière modification le 25 décembre 2024 à 05:25.

        Pour avoir eu à migrer une appli toute simple en Python (écrite par quelqu’un d’autre), simplement de RHEL7 vers RHEL8, je vois ce que tu veux dire. Le fait qu’il m’ait fallu, comme l’explique Benoît Sibaud, recourir à pip freeze pour installer très précisément la version X.Y.Z des quatre ou cinq bibliothèques utilisées (de mémoire stomp, request, … me souviens plus des autres) ça m’a surpris.

        Je suis peut-être un vieux con qui n’a rien compris à la vie, ce qui me va parfaitement jusqu’à maintenant, mais lorsqu’il s’agit d’« appli » destinée à répondre à des problématiques de devops, qui ne sont ni énormes ni potentiellement destiné à devoir « passer à l’échelle » comme on dit, je n’ai jamais rien trouvé de plus satisfaisant que Bash. Certes c’est absolument incommode à écrire, bourré de subtiles pièges plus surprenant les uns que les autres, mais une fois que ça fonctionne ça ne va pas casser aussi facilement, simplement parce qu’on passe à une version majeur supérieure du système. La plupart du temps ça fonctionne avec zéro modification. Au pire, il faut voir que Bash 5 (la version actuelle) propose des « mode de compatibilité », pour faire tourner le script écrit il y a 15 (?) ans pour Bash 3.2 et qui tourne depuis, que personne ne veut, ne peut ou n’a les moyens de ré-écrire entièrement, et que les utilisateurs finaux considèrent comme crucial de ne surtout pas perturber.

        Ce serait totalement idiot de développer des applications complexes, pour lesquelles le paradigme objet, ainsi que la cohérence et les performances brutes de l’interpréteur sont pratiquement indispensables, en Bash (ou un autre shell), mais ça me semble tout aussi idiot de se priver de l’intégration d’un shell avec le système, qui rend de fait le concept de « déploiement » anecdotique, offert par le shell en la matière.

        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.

        OK je vois. Oui le recours à un “Virtual env” pour utiliser Python c’est devenu indispensable. Il faut s’y habituer. C’était une vrai question, je me demandais si tu ne faisais pas référence au fait que pip ne permettait plus l’utilisation de sa fonctionnalité de recherche des dépendances (peut-être est-ce de nouveau possible ? Ça fait un moment que je n’ai pas fait de Python). Pour Bash la recherche, et l’installation, de dépendances ça passe par apt ou dnf, what else !? ^^

        Pour résumer le fond de ma pensée : Python est un outil formidable, mais il ne remplace pas le shell, ce sont vraiment deux outils différents, àmha.

        Ceci dit pour Python comme pour Bash, le soin à apporter à la sélection des dépendances qu’on va utiliser (leur pérennité, stabilité, notoriété) ne doit pas être négligée.

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

      Posté par  (site web personnel) . Évalué à 7 (+5/-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, Mastodon) . Évalué à 3 (+2/-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é à 5 (+2/-0).

        On peut à mon avis le qualifier de langage de programmation en bon est dû forme du fait qu’il soit « Turing-complet ». Ceci dit le Brainfuck l’est également, ce dernier est d’ailleurs le plus dépouillé que l’on puisse faire comme langage Turing-complet à ma connaissance (et c’est très beau, àmha ^^).

        Mais un shell est conçu, et de plus configuré par défaut, pour servir d’interface entre l’utilisateur et le système, pour une utilisation « interactive ». Pour prendre un des exemples les plus parlant : en Python, Perl ou d’autres langages interprétés, une erreur de syntaxe entraîne la fin de l’exécution de l’interpréteur, il « n’ira pas plus loin », alors qu’en Bash (et autres), à moins de lui spécifier de s’arrêter sur tout code d’erreur (via set -e), et donc pas uniquement les erreurs de syntaxe… il continuera, en passant à la commande suivante. C’est compréhensible : si une erreur de syntaxe stoppait ton shell, par exemple que tu te trompais et essayais d’exécuter une commande qui n’existe pas, et que tu devais alors de re-logger au système à chaque fois, tu deviendrais fou.

        Une autre manière de saisir la différence : essaye d’utiliser l’interpréteur Python comme shell de connexion, à la place de Bash. C’est techniquement tout à fait possible. Tu lances en automatique un import os histoire d’avoir des commandes (qui seront des fonctions Python donc) pour afficher/copier/supprimer/etc des fichiers, etc, etc… tu te rendras vite compte que ce n’est pas fait pour.

        Entendons nous bien, je ne veux décourager personne d’écrire des programmes en shell, c’est le langage que j’utilise moi-même le plus, mais ce que je souhaite faire passer comme message, c’est que sans prendre conscience de cela, je ne crois pas qu’on puisse avoir une bonne expérience avec Bash. On ne peut pas comparer sur un pied d’égalité un shell d’un côté, et de l’autre un langage de programmation conçu comme tel « dès le départ ».

        Certes il a un rôle particulier mais n'est-ce pas le cas de tout les langages?

        Sans aller jusqu’au Brainfuck, qui est d’abord un jeu et clairement pas un outil qui puisse rendre le moindre service en dehors de l’exercice intellectuel, oui, des langages il en existe de toute sorte (on peut prendre CommonLisp ou Erlang par exemple, relativement exotiques comparé aux langages les plus répandus), peu se ressemblent vraiement. Mais « shell interactif » c’est vraiment un rôle (et pas un paradigme de programmation…), assez à part. Selon moi, on est pas obligé de voir les choses de la même manière.

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

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

          Les pipes, c'est quand même une tuerie comme paradigme de programmation (en vrai la notion de coroutine, qui est donc un des éléments importants du langage).

          Et avec ça tu mets dans ton rétro pas mal de langages, y compris compilés, en terme de perf.

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

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

            Je vois bien le côté pratique des coroutines et des pipes.
            Cependant, je ne vois pas en quoi cela améliore les performances (par rapport à quoi d'ailleurs?).

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

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

              On utilise des programmes souvent très optimisés, multithreadés par construction, la transmission des données est bufferisée dans les pipes, on travaille par flux (capacité à traiter de gros volumes de données avec une empreinte mémoire réduite). Tout ça "gratuitement".

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

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

            Tu prêches un convaincu.

            Je pense aussi aux mots clés et built-in : wait, trap, kill voire coproc.

            Le multiprocessing en Python perso je trouve ça lourdingue à écrire.

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

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

          Mais peu importe le but du langage, l'idée est de parler du cas du langage interprété. Et de ce point Bash est 100% un langage et 100% interprété. Et d'ailleurs le point est de parler de l'importance d'un langage interprété de ne pas évoluer trop vite et de rester rétro-compatible dans le but de facilité la maintenance de programme. Et sur ce point bash est un modèle de stabilité et heureusement car bon nombre se scripts d'initialisation dont en Bash dans l'os comme les programmes. (Même OpenHEMS en utilise).

          A l'inverse on pourrait imaginer faire un interpréteur non scriptable (ce serait dommage).

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

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

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

            heureusement car bon nombre se scripts d'initialisation dont en Bash dans l'os

            De moins en moins grâce (ou à cause selon le point de vue) à systemd.

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

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

          Une autre manière de saisir la différence : essaye d’utiliser l’interpréteur Python comme shell de connexion, à la place de Bash. C’est techniquement tout à fait possible. Tu lances en automatique un import os histoire d’avoir des commandes (qui seront des fonctions Python donc) pour afficher/copier/supprimer/etc des fichiers, etc, etc… tu te rendras vite compte que ce n’est pas fait pour.

          Tu peux utiliser un shell pensé pour : https://xon.sh/

          XONSH is a Python-powered shell

          Xonsh is a modern, full-featured and cross-platform python shell. The language is a superset of Python 3.6+ with additional shell primitives that you are used to from Bash and IPython. It works on all major systems including Linux, OSX, and Windows. Xonsh is meant for the daily use of experts and novices.

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

      Posté par  . Évalué à 7 (+5/-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 (+2/-1).

        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é à 0 (+1/-2).

        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é à 6 (+4/-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é à 5 (+2/-0). Dernière modification le 25 décembre 2024 à 11:58.

        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 pré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.

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

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

          environnement virtuel dédié précisément à cette application.

          Un environnement par appli ça veut bien dire que l’on peut se retrouver avec appliA qui nécessite bibtruc.≥ X.Y.Z et appli2 qui nécessite bibtruc =X.Y.U ?

          Ce qui aura une fâcheuse tendance à l’effet boule-de-neige, avec les dépendances de dépendances, et qu’il faut donc avoir peu d’applis en cour de développement ou bien beaucoup d’espace disque à disposition ? Pas simple à gérer, sans parler de l’effort intellectuel nécessaire quand on se retrouve à devoir travailler en parallèle avec deux versions d’une lib qui sont « un peu différente » ?

          J’ai l’impression que les lib externes, il faut vraiment réfléchir à deux fois, en Python comme pour tout langage, et que « réinventer la roue », ou internaliser le morceau de code de la dite lib au sein même de son appli, vaut parfois mieux que prendre une lib pas hyper stabilisée dont on va utiliser p-e 10%, non ?

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

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

            Un environnement par appli ça veut bien dire que l’on peut se retrouver avec appliA qui nécessite bibtruc.≥ X.Y.Z et appli2 qui nécessite bibtruc =X.Y.U ?

            Je ne comprends pas trop ce que tu veux dire, mais les environnements virtuels permettent justement de résoudre ce problème.

            Avec les environnements virtuels, chaque appli a son propre système de paquets, et donc est complètement indépendante des autres.

            Un peu comme si tu faisais un chroot par appli en C, tu aurais ainsi des librairies différentes et donc pas de soucis de dépendances qui se croisent.

            ou bien beaucoup d’espace disque à disposition ?

            Pour donner une idée, je suis en train de développer un site web pour mon asso, en Python en utilisant Flask et tout un tas de trucs qui gravitent autour. L'espace pris c'est 50Mo donc bon… on gère ^^

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

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

              Posté par  . Évalué à 6 (+3/-0). Dernière modification le 26 décembre 2024 à 02:00.

              Je ne comprends pas trop ce que tu veux dire, mais les environnements virtuels permettent justement de résoudre ce problème.

              Je m’interroge sur la question de savoir si de cette solution (les venv) au problème (des incompatibilités nombreuses) ne découlerait pas un autre problème : celui de la redondance et de la complexité globale.

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

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

                Ah oui, je vois ce que tu veux dire.

                Disons que chacun va au plus vite/facile pour lui mais que en effet, globalement c'est pas super optimal.

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

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

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

              C'est bien pour faire du développement. Ça l'est nettement moins lorsque tu passes en prod sur un serveur, où tu préférerais que ça utilise les paquets Python installés via ta distribution… pour lesquels il y a normalement un suivi des problèmes de sécurité.

              Si tu as N applications packagées dans des venv il faut que, pour chacune, tu vérifies s'il n'y a pas une de ses dépendances qui a une faille.

              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) . Évalué à 4 (+1/-0). Dernière modification le 27 décembre 2024 à 10:08.

                C'est une bataille perdue : pour la sécurité, les bibliothèques devraient être gérées par la distribution et pas par un mécanisme externe (gestionnaire de dépendances, venv, docker, vendoring…).

                Ça c'est la théorie, mais en pratique :

                • il y a trop de développeurs par rapport au nombre d'empaqueteurs ;
                • le processus d'empaquetage est trop complexe et consommateur de temps pour les développeurs ;
                • certains langages sont de toutes façons mal ou pas du tout gérés par les distributions.

                Tout le monde a donc réinventé la roue (chaque langage a au moins gestionnaire de dépendances, certains plusieurs) et fait n'importe quoi (pourquoi mes libs java sont dans /usr/share/java ? les libs pythons dans /usr/lib/python3 ? pourquoi pas tout dans /lib ?).

                Et personne ne semble intéressé pour faire un début de simplification.

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

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

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

                  Et personne ne semble intéressé pour faire un début de simplification.

                  Ce n'est pas vraiment une simplification en termes techniques, mais Guix pousse à l'extrême l'approche des environnements isolés en la généralisant à tous les paquets du système. Et au final, du point de vue de l'utilisateur, c'est effectivement une simplification : un seul outil à apprendre pour mettre de l'ordre dans ce bazar.

                  Ce fonctionnement permet de garantir plein de propriétés intéressantes, par exemple (parmi bien d'autres) : installer des paquets ne nécessite plus les droits d'administrateur, plusieurs versions d'un paquet peuvent cohabiter sur le même système sans causer de conflits, les mises à jour sont "tout ou rien" (soit elle réussit, soit on reste avec la version qu'on avait, mais on ne se retrouve jamais avec un système partiellement modifié et inutilisable, même si on annule brutalement une commande de mise à jour), on peut revenir aux "générations" précédentes de son profil utilisateur ou même de tout l'OS si une mise à jour apporte des changements indésirables, etc.

                  La liste des avantages est longue, et il faut vraiment essayer ce système pour y croire (juste en lisant on se dit que c'est trop beau pour être vrai). Installer Guix et me familiariser avec était mon passe-temps pendant ces vacances, et cet essai m'a vraiment donné envie de persévérer pour finalement y migrer complètement quand j'y serai à l'aise.

  • # 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.

  • # Ah les devs ...

    Posté par  (site web personnel) . Évalué à 5 (+3/-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 :)

    • [^] # Re: Ah les devs ...

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

      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

      Moi je me suis trouvé un champion, il gère venv pour moi et je commit 3 fichiers (un lock file, un pour la version de python et un pour la description du projet) et pour les cas les plus simples (ce que je fais le plus) il peut simplement se baser sur un commentaire dans le fichier.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # java bien

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

    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…

    En Java, ajouter une bibliothèque se fait en éditant quelques lignes dans le fichier pom.xml:

    <dependency>
    <groupId>org.lwjgl</groupId>
    <artifactId>lwjgl</artifactId>
    <version>3.3.5</version>
    </dependency>
    Qu'est-ce qui est complexe là dedans ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: java bien

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

      Je n'avais pas fait gaffe mais oui on utilise énormément de bibliothèque en Java. Ce qui fait que java est différent de python c'est le classpath. Un programme java a une configuration lui indiquant la liste de ses dépendances, il n'y a donc aucun problème à avoir plusieurs versions d'une bibliothèque dans des versions différentes qui sont utilisées en même temps.

      Qu'est-ce qui est complexe là dedans ?

      C'est un peu verbeux, même maven se prépare a faire en sorte que ce soit une seule ligne (pour maven 5 il me semble, maven 4 - qui est en RC2 - étant la préparation de la version 5).

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: java bien

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

        Groovy supporte les dépendances, dans des scripts, en 1 ligne via grape/grab:

        @Grab('org.springframework:spring-orm:5.2.8.RELEASE')
import org.springframework.jdbc.core.JdbcTemplate

        On peut donc faire des scripts portables (sans compilation préalable)… J'imagine l'étonnement des futures anciens Pythonistes (dont j'étais).

        • [^] # Re: java bien

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

          Tu peux même le faire en java avec jbang.

          Mais pour l'un comme pour l'autre je n'ai pas trouvé d'IDE qui me supporte correctement. C'est à dire qui tire les dépendances et ne te met pas des erreurs partout et peut faire de l'autocomplétion.

          Kotlin a une fonctionnalité similaire en expérimentation ça décidera peut être a donner un support correct à intellij

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: java bien

      Posté par  (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 25 décembre 2024 à 04:49.

      Ce qui est bien avec Java, concernant la gestion des dépendances :

      • pas besoin de Docker ;
      • les classloaders (permettant de loader plusieurs versions d'une bibliothèque dans un exécutable, on peut bien sûr imposer des dépendances transitives) ;
      • ABI stable depuis des siècles et des siècles (coucou Rust);
      • c'est chiant de linker et de faire des binding sur du code natif (c'est entrain de changer).

      Tout est fait pour simplifier la gestion des dépendances de façon portable. C'est un compromis, dans certains cas d'usage, c'est primordial.

      Perso j'utilise énormément Gradle (je l'ai même testé à la place de cmake pour du code natif, mais je suis revenu à la raison), malgré les reproches que l'on peut lui faire, la gestion des dépendances de compilation, debug, runtime, transitive ou pas, se configure finalement simplement.

      • [^] # Re: java bien

        Posté par  . Évalué à 3 (+0/-0). Dernière modification le 25 décembre 2024 à 06:48.

        Commentaire supprimé

  • # Container ou rien

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

    En vrai les conteneurs sont une solution universelle je comprends pas qu'on s'embête encore avec des outils genre virtualenv et co.

    • [^] # Re: Container ou rien

      Posté par  . Évalué à 10 (+8/-0).

      Les marteaux sont es solutions universelles, je ne comprend pas qu'on s'embete encore avec des outils genre que tournevis, clés and co.

      NON, arrêtez de dire que les conteneurs sont des solutions universelles : les conteneurs c'est du chroot ++. Pour certaines choses c'est très bien, mais pour d'autre c'est juste pas adapté.

    • [^] # Re: Container ou rien

      Posté par  . Évalué à 8 (+6/-0). Dernière modification le 26 décembre 2024 à 01:07.

      problème : je veux exécuter un script python dans le répertoire courant.

      avec un virtual env

      setup

      python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt

      puis autant de fois que nécessaire

      nano mon_script.py
python mon_script.py mon_input > mon_output

      avec docker

      1. écrire le Dockerfile
        • from python
        • copy requirements.txt mon_script.py .
        • pip install -r requirements.xtx
        • CMD "python mon_script.py mon_input > mon_output"
      2. builder l'image qui dl la moitié d'internet
      3. lancer le container avec comme point de montage mon répertoire courant (en supposant que mon user a les droits)
      4. m'apercevoir que l'output appartient à root et que je ne peux rien en faire : sudo chown user mon_output
      5. tout répéter à chaque changement de contenu du script

      "En vrai les conteneurs sont une solution universelle" pour bien se faire ch*** pour rien.

      Les containers c'est nickel pour packager pour de la prod. Mais pour itérer en dev ….

      • [^] # Re: Container ou rien

        Posté par  . Évalué à 4 (+1/-0). Dernière modification le 26 décembre 2024 à 02:22.

        Les aficionados des la conteneurisation te diront peut-être qu’il faut utiliser Kubernetes, Rancher (et sûrement d’autres trucs additionnels) et écrire/utiliser un opérateur qui se chargera de faire tout cela à ta place ensuite. Puis développer sous Eclipse Che, c’est beaucoup mieux !

        Les containers c'est nickel pour packager pour de la prod. Mais pour itérer en dev …

        Moi aussi j’ai un peu de mal avec cette hype autour de la conteneurisation. C’est une technologie très intéressante, voire indispensable aujourd’hui, pour gérer les déploiements complexes sur des systèmes d’information immenses et protéiformes, ou pour la prod’ éventuellement comme tu le dis, mais sur de petits SI avec une topologie relativement simple, et à fortiori en tant que développeur « isolé », c’est la définition même d’overkill je trouve.

        Quand on ajoute à ça la continuelle métamorphose de l’écosystème, où tous les six mois un nouveau produit va enfin résoudre les problèmes, ce qu’il fait généralement, mais que six mois plus tard un nouveau produit est présenté comme tel, pareillement, ça donne pas une confiance terrible dans la viabilité de l’approche, et surtout pas en tant que solution universelle et évolution incontournable.

      • [^] # Re: Container ou rien

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

        Le venv n'est pas forcément suffisant s'il faut installer des paquets hors python et/ou compiler des logiciels autour. Et un venv n'est pas forcément suffisant parfois il en faut plusieurs… pipx n'est pas arrivé par hasard non plus.

        Le conteneur offre ainsi une solution en évitant de pourrir le système avec des paquets en plus (genre des python3-* ou du gcc ou …). Surtout si on a plusieurs projets en parallèle.

        Et pour finir la mode est au devcontainer pour des conteneurs de développement justement (très différents des conteneurs de prod), histoire que tout le monde sur un projet partage les mêmes outils dans les mêmes versions, que les nouveaux soient rapidement opérationnels et qu'un ordi soit facilement réinstallable.

      • [^] # Re: Container ou rien

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

        Il suffit de regarder tout ce qui tourne sur un desktop pour comprendre que conteneuriser ce n'est pas judicieux. Imaginez-vous la conteneurisation de votre machine. Il faudrait séparer des éléments qui sont faits pour interagir entre eux. Ca n'a pas vraiment de sens. C'est certainement possible sur le papier, mais on se retrouverait avec des problmatiques similaires aux architectures micronoyau, qui sur le papier sont très intéressantes, mais en pratique posent pas mal de problèmes.

      • [^] # Re: Container ou rien

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

        Les containers c'est nickel pour packager pour de la prod. Mais pour itérer en dev ….

        Ce que tu décris c'est faire ce qui est en prod pour du développement ce n'est pas ce qu'il faut faire.

        Tu utilise un dockerfile qui va bind ton dossier courant dans le container au lieu de faire une copie, c'est plus rapide et ça permet d'itérer sans problème.

        Pour faire du vite fais tu peut même te passer de dockerfile. De tête c'est de l'ordre

        name='MyProject'
# créé un container 'MyProject' en y installant les dépendances
docker run -it --name $name --mount type=bind,src=$PWD,dst=/data python:3.13 pip install -r /data/requirements.txt
# utilise le container pour l'executer ton script
docker start -it --mount type=bind,src=$PWD,dst=/data python:3.13 $name python mon_script.py mon_input > mon_output

        Tu peut soit détruire et reconstruire le conteneur quand tu change une dépendance soit faire un start pour mettre à jour les dépendances.

        Il est aussi possible d'utiliser docker compose qui va faire que tu ne joue plus qu'avec des docker compose up ou down (docker compose c'est un plugin de docker et pas un orchestrateur).

        Évidement tu peut utiliser des alias ou des choses comme just, tasks ou l'outil de build qui te plaît. Docker apporte d'autres éléments comme le fait de cloisonner ce que tu lance sur ta machine pour embêter ceux qui s'adonneraient à des supply chain attack. Et bien sûr si tu a besoin d'une base de données à côté c'est tout de même pratique.

        "En vrai les conteneurs sont une solution universelle" pour bien se faire ch*** pour rien.

        J'ai du mal à comprendre ta démarche. Plutôt que de t'interroger sur la pratique, tu pars sur ton à priori. Tu te doute bien que si certains le font c'est que c'est pratique pour eux.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Container ou rien

      Posté par  . Évalué à 3 (+0/-0). Dernière modification le 26 décembre 2024 à 03:09.

      Tu utilises CoreOS/ContainerOS sur ta machine personnelle, ou ton poste de travail professionnel si tu es informaticien ?

      Même pour les serveurs, la conteneurisation vient avec sa problématique, tout comme la virtualisation qui en possède aussi, comme elle a des avantages.

      La conteneurisation est une très bonne solution aux déploiements complexes, distribués, et avec un fort besoin de changement de mise à l’échelle rapide.

      C’est typiquement le cas d’un fournisseur de solution SaaS. Pas que, mais c’est quand même le cas le plus évident et sur lequel je pense que personne ne remet en cause la supériorité de la conteneurisation pour ça.

      Si tu as besoin d’un cluster on-pemises distribué sur deux ou trois sites comme backend pour du big-data, avec la possibilité de disposer de hardware dédié, alors y ajouter une couche de conteneurisation « parce que c’est possible et que c’est l’avenir » me semble pas judicieux.

      Je serais dans ce cas très curieux d’entendre les arguments en faveur de ce que je pense être un mauvais choix d’architecture.

      • [^] # Re: Container ou rien

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

        très bonne solution aux déploiements complexes, distribués, et avec un fort besoin de changement de mise à l’échelle rapide

        Je suis d'accord mais j'ajouterai que Docker marche aussi très bien à petite échelle.

        J'ai en prod 3 serveurs et 73 containers pour environ 25 services ; pas de gestion de cluster, tout à la main avec docker compose.

        Docker apporte beaucoup à cette échelle :

        • builder et tester sur le laptop et être à peu près sûr que ça fonctionne pareil en prod.
        • capturer la connaissance du fonctionnement du service dans le repo de source
        • isolation des services ; si un service se fait péter, il y a des chances que l'hôte n'y passe pas
        • pas de gestion des dépendances logicielles en prod ; tout a été réglé en amont
        • facile de trouver des images toutes prêtes
        • gestion des dépendances de services, des volumes de stockage, du réseau
        • léger ; je n'observe pas de charge lié à docker lui-même

      • [^] # Re: Container ou rien

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

        Si tu veux simplement faire tourner plusieurs services sur ma même machine avec chacun sa propre version de python.

        • [^] # Re: Container ou rien

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

          Python, c'est pas juste pour faire tourner des serveurs web : tu as plein de choses codés en python sur un desktop (et même sur un serveur) pour lesquels la conteneurisation n'a pas de sens. C'est pour ça que de parlmer solution "universelle" pour un conteneur est ridicule.

  • # Conseil

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

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

    En toute humilité

    1. Les logs étaient directement écris dans le /var/log/openhems, il faut un montage (Mais j'ai encore des problèmes là).

    Écris sur ta sortie standard. Ça fait parti des 12 facteurs https://12factor.net/fr/logs

    Je veux que l'utilisateur puisse autoriser manuellement la maintenance.

    Je suis pas sûr de comprendre les tenants et les aboutissants, mais ne le fait pas trop.

    Pour l'un comme pour l'autre l'idée c'est que ça n'est pas le rôle du container de s'en occuper et c'est à l'intégration de faire les choix.

    Tu peux :

    • décrire le besoin et laisser à tes utilisateurs le boulot
    • faire une installation clef en main qui demandera de faire les glues autour avec un paquet de distribution, un script d'installation ou autre
    • plonger la tête la première (le reste suivra) et packager pour un orchestrateur par exemple avec un chart helm pour kube

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Conseil

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+1/-0). Dernière modification le 27 décembre 2024 à 16:53.

      Ok pour les logs, c'est ce que je fais. Je ne connaissais pas ces précos. Merci.

      Pour la maintenance, il te faut un peu de contexte. OpenHEMS est un soit qui tourne chez le client, chez le particulier. Il doit gérer sa maison. Dans la version standard commercial, il tourne sur un mini-pc en mode serveur. Le client y accède via une interface Web. Mais en cas de problème xyz, il peut contacter le service client. Partant du principe qu'il n'y connais rien et que ce n'est pas nécessaire d'intervenir sur place, je veux qu'il m'autorise à accéder à son "serveur" via l'IHM http. Le plus simple est donc un bouton "lancer le VPN". Le serveur OpenHems se connecte alors au serveur de maintenance accessible depuis le Web et je peux m'y connecter en SSH…

      PS, L'OS est toujours le même celui que j'ai fourni en l'occurrence une base Debian pour OlinuXimo A64.

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

      • [^] # Re: Conseil

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

        Dans un contexte de container je suis un peu circonspect. Le container est immuable donc ouvrir un shell dessus ne devrait pas être d'une grande utilité, tu as évidement l'accès aux logs qui peut être utile mais ça ne demande pas d'ouvrir un shell. Si tu veux manipuler la configuration, je dirais que de la même manière ça pourrait être fait à distance via un protocole ad-hoc.

        Personnellement pour y arriver je tenterais de ne plus accéder en SSH à vos environnements de dev/QA pour vérifier ce qui peut vous manquer ou non comme info et donc appliquer les même procédures que chez vos clients en interne.

        Si par contre l'idée c'est d'accéder à l'hôte, depuis un container ça ne marche pas très bien pour vos setop box je dirais que vous pouvez faire une communication entre le container et la machine hôte pour l'activer (ou simplement ouvrir le port).

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Conseil

        Posté par  (Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 31 décembre 2024 à 09:16.

        Pourquoi n'utilises-tu pas un outil comme pyinstaller ou nuitka pour le distribuer?

        J'aurais personnellement choisi un autre langage que python et serait parti sur go, rust ou swift pour fournir des executables unique.

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.