Je n'irai pas jusque dire "arrêtez d'utiliser python" tout court mais je le pense fortement.
Je veux tester un outil appelé glogic.
Je l'installe via apt puis je tente de l'exécuter :
/usr/lib/python3/dist-packages/glogic/MainFrame.py:4: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '4.0') before import to ensure that the right version gets loaded.
from gi.repository import Gtk, Gdk, GdkPixbuf
Traceback (most recent call last):
File "/usr/bin/glogic", line 20, in
from glogic.MainFrame import MainFrame
File "/usr/lib/python3/dist-packages/glogic/MainFrame.py", line 18, in
themed_icons = Gtk.IconTheme.get_default()
AttributeError: type object 'IconTheme' has no attribute 'get_default'
totof@superbipbip:~$ glogic
Ca donne vraiment pas envie …
Alors oui on me dira certainement que c'est pas un problème python mais un problème GTK, qu'avec un autre langage ce serait la même chose mais je suis quasi certain que dans ce cas de figure le problème vient surtout de la façon dont Python gère ses dépendances.
# Le problème n'est pas GTK non plus
Posté par Christophe . Évalué à 10 (+14/-0).
Non, le souci, c'est juste que le programme est de mauvaise qualité. Il y a un warning très clair, dès la première ligne:
Donc le programme utilise Gtk, mais ne précise pas quelle version… La version la plus récente du système est chargée: pas de bol, ici ce n'est pas la bonne.
[^] # Re: Le problème n'est pas GTK non plus
Posté par Jean-Philippe Garcia Ballester . Évalué à 10 (+22/-1).
Il a été patché sur Debian précisément pour ce problème : https://sources.debian.org/patches/glogic/2.6-7/105-Require-Gtk-3.0-and-PangoCairo-1.0.patch/
À noter aussi que le programme n’est plus développé depuis 12 ans.
Difficile d’accuser python…
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à -4 (+4/-9).
Est-ce que le fait que l’erreur arrive à l’exécution n’est pas une illustration que Python n’est pas idéal pour le développement d’application ?
De ce que j’ai compris, ici @totof2000 a installé l’outil venant de la distribution.
Pourquoi l’outil n’a pas été retiré de la distribution ou corrigé ?
Pour moi, ce genre de code devrait être empêché et donc obliger à mieux écrire son programme.
C’est une chose qu’apportent les langages compilés, avoir une étape obligatoire de validation du programme. Qui permet d’attraper beaucoup plus d’erreurs avant l’exécution du programme, y compris à l’intégration continue. Est-ce qu'il existe des outils pour Python qui permettrait d'attraper des problèmes de programmation hors exécution ?
Les compilateurs, en plus de rapporter les erreurs peuvent, comme avec Rust, se montrer accompagnant en proposant, dans de nombreux cas, une solution au problème détecté.
Donc si je trouve que le journal manquait de justification, je partage plutôt l’idée "arrêtez d’utiliser python pour vos logiciels" (pour le scripting j’aurais moins de griefs). Chacun fait comme il veut, mais personnellement je vais plutôt fuir le python, aussi bien en tant qu'utilisateur que développeur.
[^] # Re: Le problème n'est pas GTK non plus
Posté par cg . Évalué à 9 (+8/-1).
Avec
dlopen(), tu peux avoir un programme qui compile mais plante de la même façon à l'exécution.Tu peux aussi compiler un programme, le faire fonctionner, mettre à jour la distrib, et hop ça ne fonctionne plus.
Avec de la compilation entièrement statique, tu n'as certes pas ce genre de problème, tu en as d'autres :).
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à 1 (+2/-2).
Oui bien sur la compilation n'empêche pas tous les problèmes, mais c'est un outil qui aide, et je pense qu'en programmation, toute aide est bonne à prendre.
D'ailleurs il existe peut-être en Python des outils type
analyseur staticqui peuvent aider, mais je n'en pas entendu parler.[^] # Re: Le problème n'est pas GTK non plus
Posté par Jean-Philippe Garcia Ballester . Évalué à 1 (+3/-4).
Comme dit au-dessus, la compilation n’empêche pas les bugs.
Utiliser un langage à typage statique en espèrant empêcher les bugs me semble dangereux.
La solution la plus efficace c’est quand même les tests, non ?
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à 2 (+3/-2).
La compilation n’empêche pas tous les bugs effectivement, mais ça réduit les bugs potentiels. Donc ça permet d’avoir plus d’espace mental pour se concentrer sur les catégories qui ne sont pas éliminés.
Les tests il faut les écrire, donc c’est du travail et c’est optionnel.
Les tests ne vont valider seulement le code qui va être exécuté, dans les conditions testées. Comment tu détermines que ça couvre tout le code ? Toutes les possibilités (exemple que ça gère des données d’entrées avec des erreurs) ?
Alors que la compilation couvre tout le code pour valider qu’il est ok, … sur ce que le compilateur peut vérifier, mais c’est déjà plus que rien.
Ensuite les tests servent pour ce qui ne peut pas être validé par le compilateur.
Du coup je pense que les deux sont complémentaires.
[^] # Re: Le problème n'est pas GTK non plus
Posté par Jean-Philippe Garcia Ballester . Évalué à 5 (+3/-0).
Je te rejoins sur certains points : typage statique et tests ne s’opposent pas et sont complémentaires.
Ceci étant, tu poses cette question :
Le débat langage statiquement typé vs dynamiquement typé existe depuis très longtemps.
Prendre l’exemple d’une application non-maintenue depuis 12 ans, pour laquelle un patch existe, ne me semble pas pertinent pour statuer sur une question si complexe ou déduire une généralité comme tu sembles le faire.
Les langages dynamiquement typés ont d’autres avantages qui s’appliquent au développement d’application.
C’est une lapalissade, mais tout langage à des forces et des faiblesses. La question est de savoir ce que tu priorises et comment tu pallies les faiblesses du langage choisi.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à 0 (+1/-2). Dernière modification le 30 mars 2025 à 22:35.
Je n'utilise pas l'exemple pour statuer, je profite de cet exemple pour partager mon ressenti/ma vision au sujet de l'absence d'étape de validation de code (ça pourrait être autre chose qu'une compilation).
Et je m’interroge aussi sur l'impact que ça a dans le fait qu'une application non-maintenue depuis 12 ans puisse rester dans les dépôts d'une distribution alors qu'elle est visiblement "cassée" (d'après le journal).
J'ai le sentiment qu'avec des langages compilés, ça réduirait un peu les risques, mais c'est pas magique, et ça dépens aussi des outils de validation des paquets mis en place.
Peut-être avec des linters Python comme cité plus bas, il y aurait moyen de détecter plus de problèmes à ce moment-là.
Je parle de validation du code à l’exécution du code au moment de l’exécution ou en amont, pas de typage statique ou dynamique.
[^] # Re: Le problème n'est pas GTK non plus
Posté par Jean-Philippe Garcia Ballester . Évalué à 2 (+0/-0).
Tu parles de vouloir un langage avec une étape obligatoire de validation avant execution. Existe-t‑il autre chose que les langages statiquement typé qui ont cette caractéristique ?
On en revient pour moi à ma première réponse, tu peux très bien avoir une étape de validation du code en amont en Python, ce sont les tests (et les linters). Il existe bien sûr des outils de mesure de couverture du code.
La compilation est pour moi une forme de test que le développeur n’a pas besoin d’écrire.
Fuir une application parce qu’elle est écrite en Python me semble peu efficace. Tu vas potentiellement éviter une application correctement testée pour utiliser une application compilée mais non testée ?
Fuir les application sans tests automatiques me semble bien plus pertinent.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à 0 (+0/-1).
Du coup une application compilée et forcément un minimum testé :)
Bien sur ce n'est pas un boycott (j'utilise par exemple synapse et borg), le langage d'une application n'est pas la seule chose que je vais regarder, mais si j'ai le choix d'une alternative
ok, je vais privilégier des applications en langage compilé.[^] # Re: Le problème n'est pas GTK non plus
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
La compilation ne réduit en rien les bugs. Un programme C plante facile. Un programme Rust moins.
La compilation permet avant tout au programme d’être plus efficient et rapide.
Ce qui évite les bugs ce sont toutes les aides. Complétion, typage, check à la compilation, tests…
Python en l’occurrence n’a pas de typage statique et c’est dommage. Mais il a d’autres outils quand même : pylint, tests automatiques sur CI/CD…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Le problème n'est pas GTK non plus
Posté par potate . Évalué à 4 (+3/-0).
Oui. Il y a des outils pour faire de l'analyse statique de codes sources Python.
Au boulot j'utilise Ruff, un linter (un outil qui, selon des règles, permet de détecter des erreurs et des mauvaises pratiques, et ensuite de lever des alertes), et Mypy, un outil de vérification statique de types. Ça ne remplace pas les tests mais ça facilite la maintenance, pour une mise en place simple.
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à 0 (+0/-1).
Ok, merci pour l’info sur les linters.
Tu penses qu’il pourrait être utilisé par les distributions linux pour vérifier, contrôler, améliorer la qualité des programmes Python qu’ils distribuent ?
Par exemple en remontant des problèmes upstream. Ou pour détecter les programmes qui ne fonctionne plus et ne sont plus maintenu ? Comme ça semble être le cas de l’exemple du journal.
Ou il risquerait d’y avoir trop de "faux positif", trop de variété de pratiques pour que ça soit un angle intéressant ?
[^] # Re: Le problème n'est pas GTK non plus
Posté par potate . Évalué à 2 (+1/-0).
Je pense que c'est déjà possible d'intégrer ce genre d'outils au packaging des applications.
Parmi les liens sur la page du wiki Debian concernant le packaging il y a des explications sur comment créer un paquet pour une bibliothèque en Python. La procédure donnée en exemple a une étape de lancement des tests. S'il faut prévoir d'ajouter une étape d'analyse statique de code à la construction du paquet elle pourrait être ajoutée là.
Mais analyse avec quel(s) outil(s) et quelle(s) configuration(s) ? La distribution peut peut-être mettre en avant des recommandations sur la façon de faire mais au final les devs doivent forcément être impliqués.
[^] # Re: Le problème n'est pas GTK non plus
Posté par Marotte ⛧ . Évalué à 4 (+1/-0). Dernière modification le 31 mars 2025 à 04:04.
Parce que ce n’est pas Debian ? Alors il y a quelques bugs qui commence à être trop nombreux et la distribution se meurt ? Quelle est cette distribution d’ailleurs ? ^^
[^] # Re: Le problème n'est pas GTK non plus
Posté par barmic 🦦 . Évalué à 2 (+2/-2).
Comme il t’ai était mentionné ça n’est pas du tout une illustration de l’intérêt de la compilation mais plutôt du link static des dépendances ou d’embarquer les dépendances d’une manière ou d’une autre (docker, nix, vm, uber jar java,…).
Le problème ne se trouve pas dans le code mais dans le packaging.
Partir d’un problème A pour dire que B le problème alors qu’il n’y a pas de corrélation entre A et B n’apporte rien au problème.
Et du coup rien de nouveau sous le soleil :
Pour le cas présent d’une application disons stabiliser je trouve que figer son environnement avec docker, flatpak ou autre me parait la meilleure idée pour acter qu’elle n’est plus développée et qu’elle demande une maintenance minimale.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le problème n'est pas GTK non plus
Posté par GwenLg . Évalué à 1 (+0/-0).
Je ne parlais pas de la problématique d'avoir un programme non maintenu qui fonctionne tel quel encore 12 ans après.
Mais de la problématique que le fait qu'il est packagé dans une distribution sans que le fait qu'il ne fonctionne visiblement plus n'ait pas été détecté (a priori). Et donc que le package n'ait pas été soit corrigé (comme l'a fait débian a priori) soit retiré.
[^] # Re: Le problème n'est pas GTK non plus
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Mais une compilation ne détecte pas ça. Elle le détecte si tu compile d'une certaine façon.
Comme quoi le fait que ce soit du python ne pose pas de problème.
Je ne suis pas certain qu'un packageur qui n'est pas vérifié que le programme se lance n'aurait pas aussi juste repris le précédant binaire sans se poser plus de questions.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le problème n'est pas GTK non plus
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 31 mars 2025 à 20:31.
Plus précisément, lancer le (pas si) nouveau programme dans le nouvel environnement et tout : si par exemple c’est installé chez moi en
venvcomme gUI, et que j’ai oublié ce détail et n’ai pas fait une réinstallation depuis le dépôt comme totof2000, je ne verrai pas que ça s’est cassé :(Le vrai problème, je pense, est que les dépendances sont/étaient mal déclarées…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Le problème n'est pas GTK non plus
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Du coup, ça ne change pas le verdict non ? Bon, le titre pourrait être plus précis : « Arrêtez de mal utiliser Python et/ou Gtk »
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Et sinon tu conseilles quoi ?
Posté par gUI (Mastodon) . Évalué à 9 (+6/-0).
C'est quoi ton soucis avec Python exactement ? Et du coup tu conseilles quoi comme langage de script ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Et sinon tu conseilles quoi ?
Posté par volts (Mastodon) . Évalué à 10 (+9/-0).
Tcl/Tk pour le GUI, c'est le bien !
* Prend discrètement la porte *
[^] # Re: Et sinon tu conseilles quoi ?
Posté par totof2000 . Évalué à -2 (+3/-7).
Peut-être entre autres un peu le même souci qu'avec XML à une époque : l'utiliser pour tout et n'importe quoi …
Peut-être que dans le cas présent, un langage de script n'était pas le plus adapté au développement de l'appli en question.
Bon, c'est vrai j'ai été un peu provocateur, mais c'est le genre de problème que je rencontre bien plus souvent avec des programmes écrits en Python qu'avec des programmes écrits avec d'autres langages.
[^] # Re: Et sinon tu conseilles quoi ?
Posté par Gof (site web personnel) . Évalué à 5 (+3/-0).
Python, mais avec Slint https://github.com/slint-ui/slint/
[^] # Re: Et sinon tu conseilles quoi ?
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Au niveau de l'accessibilité il en est où Slint? Je crois me rappeler que quand il avait été annoncé par ses auteurs ce n'était pas jojo à ce niveau là et ça tend à le disqualifier d'office comme choix pour une appli en 2025.
# Sinon chez moi ça marche
Posté par gUI (Mastodon) . Évalué à 10 (+10/-0). Dernière modification le 30 mars 2025 à 17:16.
Alors voici comment j'ai fait (je suis sur Arch, mais ça devrait rouler ailleurs) :
cd logic-3.1.0python -m venv .venv. .venv/bin/activatepip install .pip install pycairo PyGObjectglogicVoilà et surtout pas de
sudonulle part.Je soupçonne surtout que le truc est assez mal packagé en fait.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Sinon chez moi ça marche
Posté par totof2000 . Évalué à 0 (+3/-5).
C'est bien LE problème de python … enfin l'un des principaux problèmes. Devoir installer un virtualenv pour une appli GUI c'est loin d'être top (déjà devoir faire du virtualenv pour n'importe quelle appli c'est pas génial).
Je préfère largement Ruby à Python, mais pour être franc, je ne pense pas que je l'utiliserais si j'avais ce genre d'appli à développer : on pourrait je pense rencontrer les mêmes problèmes.
[^] # Re: Sinon chez moi ça marche
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 30 mars 2025 à 17:47.
Bin au contraire perso je trouve ça plutôt pratique : chacun ses dépendances et les vaches sont bien gardées.
Je n'ai pour ainsi dire aucun paquet python sur mon système et je n'ai plus de soucis de dépendances.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Sinon chez moi ça marche
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10 (+8/-0).
Du coup, si on généralise, on compile tout en statique ou alors on mets tout dans des VMs, conteneurs, jails…
C'est vrai que le packaging, c'est chiant mais bon, là, en termes d'efficacité, on commence à se rapprocher d'une application Windows qui fait 200Mo pour un hello world.
Je ne parle même pas de la place disque utilisée si tout le monde vient avec tout son attirail.
Il est loin le temps où les disques durs faisaient 20Mo.
[^] # Re: Sinon chez moi ça marche
Posté par Micromy (site web personnel) . Évalué à 2 (+1/-0).
Heureusement ! Qu'est ce que c'était limitant !
[^] # Re: Sinon chez moi ça marche
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
C’est ce que font go et rust.
Aujourd’hui on commence à voir des environnements comme ça qui ne sont plus une boite noire mais qui peuvent partager des choses. Pour le moment on a que de l’héritage et pas de composition mais ça pourrait évoluer.
Mais au final il y a quelque chose qui est de l’ordre de la logique : si tu veux pouvoir changer la bibliothèque d’un logiciel à chaud ou au déploiement alors tu déporte une partie de la QA sur la personne qui fait le packaging ou qui l’utilise et c’est ce dont se plaint le journal.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sinon chez moi ça marche
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0).
Rien ne t'y obliges.
Je ne suis pas fan de python mais tu critiques ici un langage juste pour une application seulement dont le mainteneur d'une distro en particulier a merdé.
[^] # Re: Sinon chez moi ça marche
Posté par totof2000 . Évalué à 4 (+3/-1).
Non, ce n'est pas la première fois que je rencontre ce genre de problème avec Python : je ne l'ai juste pas systématiquement posté sur Linuxfr.
[^] # Re: Sinon chez moi ça marche
Posté par arnaudus . Évalué à 4 (+1/-0).
Les problèmes de packaging de manière générale sont assez indépendants du langage, ils vont se manifester à différents moments (compilation sur le serveur du packager, installation, compilation sur la machine cible, exécution, ou jamais), ça ne veut pas dire grand chose.
Il y a très peu de langages qui gèrent les dépendances; le paradigme pour un langage de programmation c'est que l'environnement n'est pas son problème. Citer C ou C++ comme bon élève est absurde, vu que la notion même de package / library est absente du langage; la seule manière de ne pas embarquer la totalité des dépendances en copier-coller dans un seul fichier est d'utiliser un préprocesseur et un système de build. Ton exemple, ça n'est pas si différent d'un truc en bash qui appelle une commande qui n'est pas dans le PATH, ça n'est pas de la faute de bash.
Le packaging, c'est un problème profond pour lequel il ne semble exister aucune solution satisfaisante. La meilleure est celle des distributions classiques, mais elle nécessite une énorme quantité de travail et de maintenance pour que toutes les briques logicielles soient compatibles les unes avec les autres à tout moment; elles nécessitent aussi un circuit de distribution déconnecté du développeur de l'application, avec toutes les complexités que ça induit. Tout ça reste un problème logiciel, et un échec technologique majeur d'ailleurs à mon avis, mais blâmer un langage pour un logiciel mal packagé c'est vraiment se tromper de cible.
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.