Aujourd'hui, un autre journal qui dénonce grave.
Il est de bon ton de nos jours pour chaque langage de programmation qui se respecte de débarquer avec un système intégré de dépendances (ou plusieurs, mais nous y reviendrons) permettant plus ou moins automatiquement de télécharger des paquets logiciels. Souvent, il est possible de faire tourner un dépôt de paquets en interne, où l'on pourra d'une part cacher ses dépendances externes, et d'autre part envoyer ses propres paquets. L'on nommera Maven pour Java, Npm pour Javascript, Cpan pour Perl, Cargo pour Rust, Opam pour Ocaml, et même Conan pour C++ (je vais me laver la bouche au savon et je reviens). Et Pip et Conda pour Python.
J'essaie d'aimer le Python. J'essaie vraiment fort. C'est juste Python qui ne m'aime pas. Et en particulier la daube infecte qu'est Conda, Miniconda, Mamba et tous leurs amis.
Déjà, le concept d'environnement. Alors ça semble vachement malin sur le papier, pouvoir dire "aujourd'hui, je mets ma casquette de data scientist, je veux Panda, Keras, et Numpy, bim, je charge l'environnement kivabien, demain je mettrai ma casquette de webdev, et je voudrai Flask et Selenium". Sauf qu'en pratique, c'est vite le bordel, dans quel environnement je suis, comment j'en change, qu'est-ce qu'il y a dedans, comment je le mets à jour. Au point que Conda décide sans rien me demander d'aller bidouiller mon prompt pour y ajouter le nom de l'environnement courant. Non mais de quoi je me mêle ? Ça va vite être un mélasse sans nom si chaque technologique que j'utilise décide d'aller se torcher dans mon .bashrc !
Ensuite, histoire que ça marche chez tout le monde, mon équipe a mis en place des environnement partagés, c'est à dire que quand je récupère la dernière version de notre code source, régulièrement y'a des scripts qui pètent, et il faut simplement aller faire tourner une bordée de scripts moches qui vont aligner l'environnement sur ma machine. Quand ça marche.
Finalement, bien sûr, ce tas de bouse se retrouve à partir en Prod. Et comme une certaine catégorie de développeurs a décidé que la modernité, c'était d'aller chercher des petites briques partout et de les combiner de manière plus ou moins heureuse parce que ça ressemble furieusement à une compétition de qui aura le plus de dépendances, on se retrouve avec des petits scripts tout simples qui ne peuvent s'empêcher d'aller appeler un obscur paquet Python pour faire quelque chose qui tenait en une ligne de bash. Et qui débarquent avec toutes leur dépendances à la noix. Bon, et puis, ces paquets, ils sont sûrs ? Ils ont des bugs ? Est-ce que la mise à jour risque de causer des problèmes ? On s'en tamponne, #YOLO !
Pouf pouf.
Ne prenons pas les enfants du bon dieu pour des canards sauvages. Les gens qui ont développé ces trucs savaient ce qu'ils faisaient, du moins je l'espère : il s'agit à mon sens d'une approche très monoposte (et monolangage) du développement, justement d'une manière très data scientist, comme on dit. Je bidouille un truc dans mon notebook Jupyter, tiens, je ferais bien tel traitement, une ligne de commande et hop, j'ai téléchargé la chose, je teste, ça marche, super, ça marche pas, je teste autre chose. Mais le raisonnement ne tient plus lorsqu'il s'agit d'utiliser le Python comme langage de script secondaire, en équipe, et de déployer des services un poil stables en production.
Je ne connais pas la solution parfaite. Les paquets système (RPM, deb) sont stables, testés, et mis à jour de manière intelligente, mais parfois on a besoin d'une version plus récente. Faire ses propres paquets systèmes et les charger dans un Docker ou un Puppet semble bien, mais c'est un investissement en temps (et en larmes). Les systèmes de paquets liés à un langage en particulier sont vite invivables, moches et instables et pètent quand ils veulent.
Donc, allez vous faire voir, Mabma, Conda, et tous vos amis. Et non, chef, je refuse catégoriquement d'intégrer Conan à notre base de code C++ juste parce que "les systèmes de dépendances, c'est le futur", parce que là ça juste marche, alors pas touche.
Alors, s'il vous plaît, dites moi comment vous faites pour échapper à l'enfer des dépendances.
# Personnellement j'évite Python ...
Posté par totof2000 . Évalué à 6.
C'est le truc le plus moche qui existe en gestion de dépendances et de paquets. Je suis pas fan de python, beaucoup de monde le sait ici, et la gestion des dépendances est pour moi le "reflet" de l'état d'esprit du monde python.
Je ne dis pas que je n'ai jamais eu de problèmes avec ruby, mais je trouve que c'est beaucoup plus cohérent. Et même nodejs et npm me posent moins de souci.
Je pense que le meilleur moyen de gérer ce genre de souci avec Python, c'est de tout faire dans un conteneur. Et éviter Python comme langage de script secondaire. C'est certes un investissement en temps, mais une fois que c'est fait, on arrive à s'en sortir. Et l'avantage d'un conteneur, c'est que ton image, une fois en prod, tu la versionnes et la stocke dans un repo d'image. Et elle fonctionnera toujours. Si tu dois générer une image version N+1, et qu'il y a un problème, tu peux toujours revenir à la version N. Et avec un bon système de build (chaine de CI standardisée) tu masques une grande partie de la complexité aux devs.
[^] # Re: Personnellement j'évite Python ...
Posté par Astaoth . Évalué à 9.
NPM pose le problème très concret de supply chain attack. Ca s'est déjà produit, et ca se reproduira.
Emacs le fait depuis 30 ans.
[^] # Re: Personnellement j'évite Python ...
Posté par Lucky Seven . Évalué à 10.
Il y en a eu en Python aussi, et ca se reproduira.
https://www.bleepingcomputer.com/news/security/malicious-pypi-package-opens-backdoors-on-windows-linux-and-macs/
Ce n'est pas dû au langage, mais à partir du moment ou l'on utilise une dépendance écrite par quelqu'un d'autre, on n'est jamais à l’abri.
[^] # Re: Personnellement j'évite Python ...
Posté par Astaoth . Évalué à 5.
Ce n'est pas directement dû au langage, mais à la gestion de ces dépôts de bibliothèques. Malheureusement les procédures sont beaucoup plus laxistes que pour des dépôts de distributions.
Emacs le fait depuis 30 ans.
[^] # Re: Personnellement j'évite Python ...
Posté par StyMaar . Évalué à 3.
Comme tous les gestionnaires de dépendances sans validation explicite pour ajouter du code au dépôt, c'est vrai pour npm, pour pip, pour cargo, pour les ppa …
D'ailleurs dans l'absolu même les dépôts debian ne sont pas à l'abri d'une supply-chain attack non plus (même si la barre est plus haute): si quelqu'un parvient à usurper l'identité d'un mainteneur en vacances, tu peux te retrouver avec une bibliothèque vérolée … Des trucs comme ça sont déjà arrivés sur npm. Après on peut imaginer que le côté communautaire de Debian rend la barrière plus dur à franchir.
[^] # Re: Personnellement j'évite Python ...
Posté par Astaoth . Évalué à 5.
En effet, dans l'absolue ca peut arriver sur n'importe quel système utilisant des dépôts. En pratique, ca n'est pas arrivés sur les dépôts de grosses distributions, par contre ca commence à devenir courant pour certains langages.
Emacs le fait depuis 30 ans.
[^] # Re: Personnellement j'évite Python ...
Posté par freem . Évalué à 5.
D'ailleurs, je me dis, Perl utilise un repo, et je n'ai pas souvenir d'avoir vu ce type de problèmes dans les infos?
Pour ceux qui ont été affectés, je dirait: JS, python, et… c'est tout, non? Rust n'as pas encore été ciblé? Quels autres langages ont été affectés, en fait?
[^] # Re: Personnellement j'évite Python ...
Posté par barmic 🦦 . Évalué à 6.
Parce que le dernier qui a déployé du code sur cpan c'était en 1997 :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Conan
Posté par rewind (Mastodon) . Évalué à 6.
Conan est écrit en Python, c'est pour ça que tu n'aimes pas :) Moi non plus j'aime pas Conan.
[^] # Re: Conan
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10.
C'est barbant en effet.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Conan
Posté par Christophe . Évalué à 10.
Voire barbare
[^] # Re: Conan
Posté par El Titi . Évalué à 7.
et destructeur
[^] # Re: Conan
Posté par BAud (site web personnel) . Évalué à 6.
ou conquérant
[^] # Re: Conan
Posté par jsbjr . Évalué à 3. Dernière modification le 21 août 2022 à 15:44.
Vous lui reprochez quoi à Conan?
A part le fait que se soit très lié à Artifatory (qui n'est pas libre je pense)
Nous l'utilisons un peu au boulot et ça s'intègre assez bien dans notre façon de travailler.
[^] # Re: Conan
Posté par rewind (Mastodon) . Évalué à 10.
Personnellement, mon principal reproche envers Conan, c'est d'être en Python. J'ai rien contre Python (même si c'est clairement pas mon langage préféré), mais devoir installer une seconde stack logicielle pour pouvoir installer des packages d'une première stack logicielle, je trouve pas ça très optimal pour le coup. Je sais bien que la RAM et les SSD ne sont pas chers de nos jours mais quand même.
Je remarquerai juste que le même genre d'outil, dans les autres langages, est implémenté avec le langage en question. Ça me paraît logique, «eat your own dog food» comme on dit. Même CMake, qui n'est pourtant pas le meilleur outil de build qui puisse exister, il est fait en C++, ils sont donc capable de savoir ce que sont les problèmes dans la construction d'un logiciel en C++ puisqu'ils y sont confrontés tous les jours.
En plus, c'est pas comme si ce genre de logiciel existait déjà, écrit en C++ (apt toussa). Si je devais me lancer dans un projet de gestionnaire de dépendances, je commencerais par forker apt/dpkg et ensuite, j'adapterais pour le cas d'usage visé dans le journal (et attendu par toute une communauté C++) : pouvoir installer un environnement de développement avec plein de dépendances pour le C++.
[^] # Re: Conan
Posté par jsbjr . Évalué à 3.
Merci pour la réponse.
Je comprends l'argument de vouloir éviter d'avoir à utiliser un environnement de développement supplémentaire.
Chez nous c'est déjà le cas de toute façon. Notre cible de développement c'est des micro-controlleurs, sans OS.
Donc quand on compile, on est dans un environnement complètement différent. Donc utiliser du C/C++ ou du python pour gérer les dépendances/compiler/tester/distribuer c'est pareil il faut de toute façon programmer différemment.
Pour compiler on utilise SCons et on a une grosse base de code écrite en Python donc Conan est adapte à nos besoins.
Pour apt et compagnie je ne crois pas que beaucoup permettent d'installer facilement en même temps plusieurs versions du même paquet sur la même machine.
Et fonctionnent sous Windows, parce que malheureusement on a ça aussi au boulot.
Par contre si je devais écrire un outil de ce genre c'est sur que j'irai voir comment apt/rpm/pacman/cholatey fonctionnent et si je ne peux pas les réutiliser.
[^] # Re: Conan
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si conan n'est pas top, vous utilisez quoi ? un script bash qui fait des git clone ?
"La première sécurité est la liberté"
[^] # Re: Conan
Posté par rewind (Mastodon) . Évalué à 3.
Ça dépend. Sur ma Debian, j'utilise les paquets de ma Debian. Sur Windows, j'utilise vcpkg. Il m'arrive aussi d'utiliser vcpkg sur Debian quand je veux faire un bon gros binaire statique.
# Utilise poetry
Posté par davandg . Évalué à 8.
Poetry c'est trop bien, ça marche chez moi©. On utilise ça dans ma boite, on a jamais eu de problèmes.
Enfin si, on a des problèmes liés à ce qui n'est pas géré par poetry: les dépendances binaires. Et là, soit tu dis "démerdez vous nous on gère que la version X", soit tu passes par Nix, mais là la complexité explose.
[^] # Re: Utilise poetry ou pex
Posté par MrBidon . Évalué à 3.
Je suis très fan de pex pour le packaging et déploiement d'application Python. C'est vraiment ce que j'ai trouvé de plus facile.
https://github.com/pantsbuild/pex
[^] # Re: Utilise poetry
Posté par flagos . Évalué à 9.
A mon boulot, ca va faire un an et demi qu'on l'utilise et on commence à avoir de sérieux problèmes avec. L'ajout d'un paquet, selon sa place dans l'arbre des dépendances, peut entraîner plusieurs heures de calcul. Le dernier en date m'a pris pas loin de 12 heures !
On est même pas si bloated que ça, le souci est du a une histoire de metadata non déclarée sur le repository, qui force poetry a télécharger tous les paquets candidats potentiels. (https://python-poetry.org/docs/faq/#why-is-the-dependency-resolution-process-slow)
Du coup, la "solution" consiste à faire poetry add sur une VM un peu costaud avec une bonne connexion et un bon disque…
[^] # Re: Utilise poetry
Posté par Arvil . Évalué à 2.
Il mentionne Nix, j'applaudis des deux fesses. Merci !
# Réinventer la roue
Posté par Michaël (site web personnel) . Évalué à 7.
Un des poncifs de la programmation est l'expression ”qu'il ne faut pas réinventer la roue” — négligeant que celui qui sait réinventer la roue est au passage tout sauf un potiron. C'est en suivant un peu aveuglément ce poncif mille fois ressassé qu'on se retrouve avec des milliers de dépendances banales et parfois un peu triviales, or comme tu le dis
et c'est justement difficile d'écrire un bon système de dépendances! Or là tout le monde réinvente la roue, encore et encore! Il faut aussi souligner que le problème de la résolution de dépendances des paquets n'est pas facile, c'est même un problème NP-complet et avec un peu de soin on peut montrer que le problème de l'installation est équivalent au problème de la satisfaisabilité d'un polynôme booléen. Autrement dit, c'est exactement le type de problèmes où la réinvention de la roue.
Pour le problème concret qui pousse à cela c'est qu'on voit malheureusement que la distribution de logiciels sous Linux est un cauchemar et qu'il n'y a pas de solution satisfaisante offerte par les gestionnaires de paquets “traditionnels”. (Au passage les systèmes de ports à la BSD ou MacPorts eux tirent assez bien leur épingle du jeu pour la distribution de logiciels “maison”.)
Une solution pragmatique est celle d'utiliser un environnement de type docker pour distribuer “le python officiel” de l'équipe pour le projet mais cela ajoute un petit peu de complexité dans le cycle de développement.
[^] # Re: Réinventer la roue
Posté par flan (site web personnel) . Évalué à 10.
C'est difficile, mais tout le monde réinvente la roue sans trop de poser de question, malheureusement.
Au final, on se retrouve avec plein de solutions différentes, avec toutes des inconvénients différents (certaines plus que d'autres).
Quelques défauts à travers des différents formats que j'ai fréquentés :
- le miroir est codé en dur (snap)
- le protocole et le port sont codés en dur (docker)
- l'index est constitué d'objets sérialisés (Ruby) donc presque illisible dans un autre langage (à moins de recoder la désérialisation d'objets Ruby)
- pas de signature de l'index (Ruby, …)
- plein de fichiers à télécharger (apt) ce qui rend le mirroring compliqué
- l'archive ne contient pas (toujours) toutes les métadonnées (java)
- pas de schéma de numérotation de version imposé (Python, Ruby, npm, …)
- système de signature spécifique à un OS (WinGet, de mémoire)
- formats d'archives peu classique (.deb qui utilise des ar)
- un service tiers est codé en dur (Ansible Galaxy, qui se repose sur le fait que Github ne change pas ses URL et reste gratuit)
- un protocole qui compte beaucoup sur les headers HTTP, donc impossible d'utiliser un autre protocole (Docker)
- un index basé sur git, donc compliqué à reproduire (Rust)
- protocole à moitié codé en dur (apt fonctionne mal en file://)
[^] # Re: Réinventer la roue
Posté par freem . Évalué à 10.
Je ne connais pas la plupart des points soulevés, mais je suis intrigué par certains:
Je ne pense pas qu'il soit pertinent de chercher a dupliquer la totalité des paquets de l'archive Debian pour se monter une reprepro local à la boîte, pour le coup. Un système de type serveur sous Debian, avec une install raisonnée, le coeur du système tiens sur environ 300 paquets, chaque nouvel fonctionnalité apportant sont lot de paquets (et ça peut monter très vite selon les technologies, c'est vrai, mais ce n'est pas lié à apt) mais je doute très fortement qu'une boîte ait besoin de tous les DEs et leur tétrachiée de dépendances…
La, vraiment, je ne comprend pas comment on peut sérieusement mettre ça dans un message intitulé "réinventer la route"… Tu parles d'un format d'archive qui existe depuis 1971 selon wikipedia, et qui est actuellement toujours très utilisé pour… la compilation d'outils natifs.
Accessoirement, selon wikipedia dpkg a reçu sa première version en 1994, et est antérieur de 3 ans à rpm (et la, de ce que j'ai lu on est effectivement dans la réinvention de la roue, carrée qui plus est, mais je ne connais pas les raisons historiques).
Je ne défend pas les autres technologies, parce que je ne les connais pas assez, mais de ce que je vois de tes critiques sur .deb et apt, je ne suis pas convaincu que ça soit super fondé.
[^] # Re: Réinventer la roue
Posté par freem . Évalué à 2.
Je voulais bien entendu dire "réinventer la roue", pas la route.
[^] # Re: Réinventer la roue
Posté par flan (site web personnel) . Évalué à 3.
Si, ça arrive. Personnellement, j'ai toujours bossé sur des environnements sans accès à internet, donc avec des copies complètes des dépôts en local (faisable avec du Debian ou Ubuntu, mais rarement faisable avec les dépôts de langages comme Python ou npm qui sont énormes).
ar existe depuis longtemps, mais est très peu utilisé en comparaison de zip ou tar.XX, et surtout n'est facilement utilisable qu'en ligne de commande (tu n'as pas de version Python, par exemple).
[^] # Re: Réinventer la roue
Posté par freem . Évalué à 3.
C'est vrai, il peut y avoir des cas d'usages. Désolé d'avoir été aussi péremptoire. Mais je pense que c'est loin d'être la majorité, ou alors tu va me dire que tu utilises du haskell, du java, du C#, du C, du python, du JS, du perl et whatnot dans la même boîte?
Bon, techniquement, perl sous debian t'as pas le choix, python n'est pas le plus simple a esquiver et maintenant ils commencent a mettre JS en dépendance obligatoire des paquets de documentation (ce qui me fait vraiment chier, au passage), mais l'idée est la: je doute sincèrement que l'accès à la totalité de l'archive Debian soit nécessaire dans la plupart des cas.
Par contre oui, ça se fait, et plutôt bien, tant qu'on a l'espace disque. L'avantage est qu'il suffit de pomper la totalité d'un repo http sur un serveur et ça juste roule avec des outils comme reprepro.
Il fut une époque ou python était très peu utilisé, lui aussi. Troll à part, tu as raison, mais il n'empêche qu'on ne peux pas parler de réinventer la roue quand quelqu'un utilise
ar, surtout quand le projet en question est loin d'être jeune.Je ne connais pas l'historique derrière ce choix, mais il me semble très clair que pour critiquer ce choix, il faut critiquer en fonction de l'existant à l'époque, et des performances des autres solutions à ce moment. De nos jours, changer ça risquerais de casser bien des systèmes pour un gain bien faible (si ça marche, ne répares pas!).
Et de ce point de vue, l'usage de
tarpour tout et n'importe quoi est aussi risible: le besoin initial était d'archiver sans perte de place sur des lecteurs de bande!Je serais curieux de connaître la raison du choix de
arau lieu detarou des autres formats de l'époque cela dit (zip?). Si quelqu'un à une info ou une piste, je suis preneur.[^] # Re: Réinventer la roue
Posté par flan (site web personnel) . Évalué à 2.
En pratique, il est bien plus simple de cloner l'intégralité du miroir Debian qu'une sélection de paquets. D'autre part, il est vite pénible d'ajouter progressivement les paquets alors qu'un miroir Debian ou Ubuntu ne pèse rien (dans les 200 Go).
Par contre, dans les structures que j'ai connues, il y avait un peu de tout (Python, Java, Ruby, C, C++, PHP, JS …), donc besoin de miroirs pour ces langages.
Ça tombe bien, je n'ai jamais parlé de réinventer la roue mais d'avoir des défauts. Je considère en effet qu'utiliser deux formats d'archives différents, dont un peu fréquent avec peu de bindings dans les langages classiques, est un défaut.
[^] # Re: Réinventer la roue
Posté par totof2000 . Évalué à 4.
Euh … c'est une question de point de vue. Debian était là bien avant tout ça non ? Du coup, ne serait-ce pas la faute des langages classiques qui n'implémentent pas le binding en question ?
[^] # Re: Réinventer la roue
Posté par freem . Évalué à 2.
Pour le fait que le format pourrait être mis à jour, je suis d'accord, sur la théorie du moins (en pratique, forcément, c'est pas la même done).
[^] # Re: Réinventer la roue
Posté par flan (site web personnel) . Évalué à 3.
Pour Debian, ces défauts sont compréhensibles car le format est vieux.
Certains défauts sont beaucoup moins acceptables pour des systèmes plus récents qui n'apportent rien aux systèmes déjà existants alors qu'ils auraient pu en reprendre un. La résolution des dépendances est un problème résolu du côté du client, qui est complètement indépendant du dépôt. Par exemple, poetry (client pypi) a un algorithme de résolution de dépendance différent de pip.
[^] # Re: Réinventer la roue
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
Ah ah ah ! J'ai quand même une bonne trentaine de projets personnels qui utilisent intensément
aret je ne pense pas être le seul. Dès que tu dépasses 1000 lignes,arest indispensable.your argument is invalid
[^] # Re: Réinventer la roue
Posté par flan (site web personnel) . Évalué à 1.
ar existe depuis longtemps et utilisé dans des cas bien précis, mais est finalement très peu utilisé en comparaison de zip ou tar.XX, et surtout n'est facilement utilisable qu'en ligne de commande. Si tu veux faire du Python (comme c'était mon cas), tu n'as pas de de moyen de l'utiliser aussi simple que pour faire du zip ou du tar.gz (i.e., bibliothèque standard ou purement Python).
# c'est quoi le problème des .deb?
Posté par freem . Évalué à 10.
Pour l'avoir fait moi-même dans mon précédent job, faire un script qui génère des paquets binaires (j'insiste, parce que les paquets source c'est plus chiant, faut se taper toute l'usine a gaz pour build) pour les .deb est trivial, tant que tu ne t'embêtes pas a utiliser les scripts
pre-rm,post-rm,pre-instetpost-int.Concrètement, il suffit de faire un dossier
DEBIAN, d'y écrire un fichiercontrol, 2-3 autres fichiers qui détaillent les hash et les dépendances, de lancer undpkg-debavec l'option kivabien (je me souviens plus de son nom, ça date, maisapt-file show dpkg-devdevrais pouvoir t'aider), d'upload vers un serveur http géré par, il me semble,reprepro.Tout ça s'automatise super facilement, vraiment. Je me suis débarrassé d'un tas de problèmes grâce à ça, malgré que je n'étais entouré que de "jeunes" développeurs, sortis de l'école (ou qui n'avaient pas touché au code depuis 30 ans littéralement) et 0 compréhension de comment une debian tourne.
Ce qui est magique avec le format .deb, c'est que c'est juste une archive standard (qui contiens un fichier texte qui décrit la version, 1 archive de meta-données, et 1 archive qui contiens la charge utile), donc tu peux simplement mettre en place ce genre de trucs juste en ouvrant les paquets qui marchent, même pas besoin de lire la doc!
Il me semble que pour rpm ce n'est pas la même chanson, mais je n'en ai réellement aucune idée.
Le seul inconvénient de dpkg, c'est qu'il a "besoin" d'être root, mais… en vrai je pense que c'est faux, si on joue un peu avec les paramètres (de mémoire on peut ajuster ce type de paramètres) et qu'on le pointe sur des dossiers accessibles par des UID!=0. Pour dpkg, ça peut marcher, je pense, mais pour apt ou aptitude, c'est moins évident.
Pas sûr non plus que ça soit pertinent, après tout il suffit de coller une MàJ automatique des paquets dans une cron-tab, disons, le midi, et ça juste roule.
Après, la où les larmes risquent effectivement de couler, c'est quand tu vas essayer de convaincre tes collègues, à cause d'une mauvaise réputation (liée au fait que pour contribuer un paquet, il faut que ça soit un paquet source, et suivre les procédures debian, ce qui est normal… mais ici on parle d'un truc en interne, non?), ou si tout le monde ne marche pas sur une Debian-like…
De mon côté, j'avais bricolé un script shell sur quoi? 150 lignes? Il lisait un fichier texte qui décrivait les données a empaqueter et faisait office de "super-control", je gérais 2-3 bricoles automatiquement (l'archi matérielle, c'est trivial, l'auteur idem, et quelques autres bricoles YMMV) et l'outil était utilisé pour empaqueter:
En tout je devais avoir bien une 40aine de paquets… et franchement je n'ai jamais regretté mon choix. Il faut dire que je n'ai eu que moyennement le choix, vu qu'il fallait bien automatiser le déploiement via PXE, et clairement passer sur des .deb était de loin le moins prise de tête.
A l'origine, j'avais déployé le PXE à l'arrache et dans l'urgence, je dézippais littéralement des tarballs dessus après le debootstrap, et ça a été la cause de bien des larmes, justement, jusqu'à ce que je me bloque quelques heures pour faire ce fameux script, et la, magie, une source de galères au déploiement en moins, tout en n'utilisant que des trucs simples (pas de nouvelle dépendance, c'est agréable quand le système de destination est une beaglebone black ou une CM mano842 avec ses 8Gio de stockage… et même sans ça, c'est plus simple de s'assurer que tout marche, quand il y a moins de 400 .deb installés!).
Bon, de temps en temps un collègue ne comprenait pas pourquoi mon script refusais de tourner, dans ces moments je le débloquais, j'améliorais le message d'erreur, et j'améliorais la doc. Au fur et a mesure ces moments étaient de plus en plus rare, et oui, ils utilisaient parce qu'il n'y avait de toute façon aucun autre moyen de déployer :)
[^] # Re: c'est quoi le problème des .deb?
Posté par Krunch (site web personnel) . Évalué à 5. Dernière modification le 22 août 2022 à 10:57.
Pour dpkg sans root il y a FakeRoot : https://wiki.debian.org/FakeRoot
En pratique j'ai plus d'expérience pour builder des RPMs et j'ai l'impression que c'est comme même bien plus simple (et, oui, j'utilise Debian au quotidien mais de nos jours je build pas de .deb ou de .rpm du tout).
Cela dit, de manière générale, j'approuve l'utilisation du système de dépendance de la distribution plutôt que de faire ça par language/environnement. Après ça dépend un peu du cas d'utilisation.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: c'est quoi le problème des .deb?
Posté par freem . Évalué à 4.
C'est un truc qu'il faudrait que j'arrive a me motiver pour utiliser, mais bon, entre fakeroot, fakechroot, fakeroot-ng, et leurs configs, j'avoue avoir la flemme et avoir tendance a juste chroot. Simple, efficace, même si ça requiert un compte root.
Je pense qu'il y a moyen en fait de faire tourner dpkg sans les droits root. D'ailleurs, un essai rapide avec:
Ca semble marcher.
Du coup, lui dire qu'on s'en fiche de pas être root, parce que bon, hein… et spécifier le chemin qu'on veut. Je pensais que ça aurait été plus compliqué en fait. Comme quoi, suffit parfois vraiment de se sortir les doigts.
Bon, j'ai pris busybox-static pour une raison: c'est le moins risqué.
Mais dans l'hypothèse ou l'on a des paquets qui sont conçus pour ne pas nécessiter un accès root à l'installation, ça devrais vraiment pouvoir fonctionner. Typiquement, pour des programmes interprétés, et non compilés (parce que pour les compilés, ldconfig & consorts)…
# Vision Data scientist ?
Posté par tallion . Évalué à 5.
Bon, je dois l'admettre étant data scientist, cela m'a un peu piqué…
Après, vu que le nom reste un peu récent, beaucoup dans ce métier ont oublié la partie "science" et il y a peu de senior avec des bonnes pratiques.
A chaque nouveau, on doit expliquer qu'intégrer une dépendance nécessite a minima de valider le risque d'abandon, la licence, la maintenance…
Sinon ce qui m'étonne dans ton analyse, c'est qu'à part sur le bash (conda…), la plupart des remarques ne sont pas sur la gestion des dépendances mais plus sur les mauvaises pratiques de ceux qui l'utilise. En tant que dev C++, j'imagine que tu vois la séparation entre avoir la possibilité et le faire.
Pour ma part, conda me permet de gérer le python et je reste sur les outils classiques pip/pipx and co (en fait ce qui est dans pypa), ma gestion avec le pyproject.toml et cela marche plutôt bien (même les dépendances avec la pep 621 car je pense pas qu'on aura la 582).
Donc en restant sur du clean et des bonnes pratiques, le seul bémol que je vois c'est le poids de la stack python pour un cli et parfois la lenteur…
[^] # Re: Vision Data scientist ?
Posté par jyes . Évalué à 6.
Alors, j’ai une question que je n’ai encore jamais oser poser, mais j’assume aujourd’hui que je ne comprends rien à Python. Python, ça marche très bien sur ma Debian à coup de paquets installés via APT, mais un jour, j’ai voulu créer un environnement de développement « contrôlé » pour pouvoir distribuer un script et ses dépendances proprementet les exécuter sur un autre ordinateur. Après beaucoup (mais peut-être pas assez) de lectures de la forme « pipx fait comme pip mais en bien », « pip, c’est comme conda mais sans les défauts » et les « poetry, c’est comme pip et pipx, mais en plus pratique en plus on peut tout utiliser ensemble », j’avoue n’avoir rien compris à quelle sont les bonnes pratiques. Et ça, c’est sans compter que chaque outil à plusieurs manière d’être installé et d’installer les modules qu’il gère et que tous ces outils semblent être faits pour être installés à partir de l’un des autres.
[^] # Re: Vision Data scientist ?
Posté par beleys (site web personnel) . Évalué à 5.
En fait, ce cas est prévu et il faut passer par les environnements virtuels.
Associé à pip, tu peux te monter un environnement pour chaque projet en quelques minutes et switcher très facilement.
Voici un lien sur la doc de référence.
https://docs.python.org/fr/3/tutorial/venv.html
Si tu poursuis ton utilisation de Python, tu verras que cela devient la "norme" de travailler dans de tel environnement et que c'est l'inverse qui est une mauvaise pratique.
Le thread est assez anti Python ^ mais pourtant, ancien dev C++ et Java … Je ne travaille quasiment plus qu'en Python. Pas tant pour le langage en lui même mais pour son environnement.
[^] # Re: Vision Data scientist ?
Posté par François (site web personnel) . Évalué à 5.
Poetry c'est pour développer, gérer ton pyproject.toml, gérer les dépendances et leur version dans un environnement virtuel (aucun lien donc avec les lib installées par le système) et spécifier la version de python requises.
Sans rien en plus c'est la version système de python et sa bibliothèque standard qui est utilisé. Sinon il faut utiliser pyenv.
pip permet d'installer des paquets de pypi, dans les environnements virtuels notamment, mais poetry fait déjà ce job.
Poetry permet de publier sur pypi également.
Si ton paquet contient des scripts, ou des "entry points", alors pipx permet d'installer ton paquet, ton programme, de manière isolée des autres avec toutes ses dépendances, et sait mettre à jour. Génial. J'installe comme ça black, ranger-fm, et même spyder.
Si tu veux distribuer ton programme, si il est simple, regarde de côté de zippapp de la bibliothèque standard. Dans ce cas tu restes dépendant de la version python utilisé par l'utilisateur. Shiv est plus complet.
Sinon regarde du côté de pex, nuikta, pyinstaller, voir appimage.
[^] # Re: Vision Data scientist ?
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 4.
Le problème principal avec l’écosystème de gestion de paquets de Python, c’est qu’il est totalement en contradiction avec le principe « There should be one-- and preferably only one --obvious way to do it. » (PEP 20). Il y a beaucoup trop d’outils et de façons de faire, que ce soit pour générer des paquets ou pour les installer dans des environnements isolés.
Cette promesse est par contre très bien tenue par Julia : il n’y a qu’un seul gestionnaire de paquets (Pkg.jl), qui est capable de gérer des environnements isolés (des projets, en jargon Julia). Et pour créer un paquet, il suffit d’un fichier de description (Project.toml) et d’une arborescence de fichiers qui suit la convention (ce qui peut être généré automatiquement par PkgTemplates.jl).
[^] # Re: Vision Data scientist ?
Posté par ff9097 . Évalué à 2.
Les virtualenv dépendent quand même de la version de python du système, il n'est pas possible d'avoir deux environnements avec deux versions de python différentes.
[^] # Re: Vision Data scientist ?
Posté par flagos . Évalué à 8.
Tu specifies la version de python que le virtualenv doit utiliser avec l'option -p. Le truc assez ultime, c'est d'aller recuperer une install python avec pyenv, et de l'utiliser avec ton virtualenv.
Bref, pour te répondre, oui tu peux tout a fait avoir 2 virtualenv avec 2 versions de python differentes.
[^] # Re: Vision Data scientist ?
Posté par jyes . Évalué à 4.
Merci !
C’est la première réponse synthétique que je trouve et qui donne une piste claire à suivre. Je suis en train de tester pyenv. De ce que j’en constate pour le moment, pyenv + virtualenv pourrait bien être la combinaison qui me fera changer d’avis sur Python. L’avenir me le dira… mais je te remercie dès à présent pour cette piste !
# Parfaitement d'accord
Posté par PBellicano . Évalué à 6.
Merci! Je viens de me re-connecter à LinuxFR alors que cela faisait 10 au minium. (De toute façon, j'étais toujours à contre sens de la communauté.)
Les dépendances style apt rpm ebuilds liées au système, ce n'est pas top mais en étant modérés dans leurs usages, cela peut bien se passer. Mais au niveau de Python, Conda, (tous ceux que tu cites), c'est "à pleurer". J'ai tenté Python au moins 4 fois ces dernières années pour plusieurs projets et ce fut pénible, difficile, compliqué dès qu'il fallait utiliser des librairies car, et c'est là où cela devient amusant, c’était bien pour la présence de cette immense gamme de librairies que j'ai été "poussé" par certains collègues/amis vers Python… Quelle ironie! C'est quand tu veux utiliser les diverses librairies que cela commence à ne plus marcher et tu passes alors des heures, voir des dizaines d'heures à pouvoir rendre l'ensemble fonctionnel en sachant très bien que cela sera encore plus difficile à faire fonctionner sur le serveur de production!
J'ai donc abandonné à chaque fois. (alors même que j'avais déjà fait de beaux avancement dans un Jupyter hébergé je ne sais où).
Tu poses +- la question de savoir si les créateurs d'environnement (le terme me fait déjà bien rire) savent ce qu'ils font. Eh bien, oui et non. Oui car ils connaissent la complexité de ce qu'ils élaborent et non car beaucoup d’informaticiens sont encore des geeks/no life/no sport (même passé les 30 ou 40 ans) qui considèrent que passer du temps à faire fonctionner quelque chose qui théoriquement est bon n'est pas un problème car ce qui compte pour eux, c'est idéologie et non la pratique. En d'autres termes, perdre du temps à faire fonctionner quelque choses dont l’idéologie leur plait n'est pas un problème (je les soupçonnent même de trouver cela valorisant!).
Tout ça, c'est mon avis. Hein!
# Maintenance
Posté par arnaudus . Évalué à 10. Dernière modification le 22 août 2022 à 15:19.
Est-ce qu'au final on n'est pas simplement en train d'acter le fait que personne ne souhaite maintenir les logiciels?
Traditionnellement, l'évolution des logiciels (compilateurs, systèmes de build, bibliothèques tierces…) demande une maintenance permanente. Ça ne compile plus avec le nouveau gcc parce qu'il est plus strict sur les erreurs de syntaxe, il faut réécrire le code pour s'interfacer avec la dernière API de libxml, il faut contourner un bug du compilateur sur telle ou telle architecture, etc. Un projet actif demande de toujours bricoler pour fournir des paquets qui fonctionnent sur plusieurs OS ou plusieurs distributions. C'est casse pied, mais c'est le prix à payer pour s'assurer que le logiciel soit utilisable, qu'il soit compilé avec des options d'optimisation plus efficaces, qu'il soit compatibles avec les nouvelles technologies, et qu'il s'appuie sur des versions à jour (débuggées, sécurisées, et optimisées) des bibliothèques externes.
J'ai l'impression que l'écosystème actuel n'accepte plus ce coût, et voudrait que les logiciels fonctionnent pour toujours comme au jour de la publication de la première version. Avec un Python d'il y a 10 ans, avec des dépendances qui n'ont pas été touchées depuis 15 ans, avec des interfaces graphiques qui datent de Windowmaker… Si les dépendances sont trop chiantes, paf on distribue le binaire compilé d'un bloc, et si ça marche pas, paf on te met ça dans une machine virtuelle, ça juste marche.
Conda et compagnie, c'est quand même par design pour pallier les trucs pas maintenus, qui ont besoin d'une combinaison précise de dépendances pas à jour, ou pour faire tourner la dernière version d'un logiciel sur un serveur pas super à jour. C'est plus dans nos pratiques collectives de maintenance qu'il y a un problème, non? Je ne vois pas comment ça pourrait être résolu magiquement en bloatant les machines avec 127 versions de chaque dépendance et en priant pour que le système de build et l'environnement de développement trouve la bonne et se débrouille pour trouver quelque chose de plus ou moins compatible sur chaque machine où le logiciel sera distribué…
[^] # Re: Maintenance
Posté par arnaudus . Évalué à 6.
Je me réponds à moi-même, mais pour le principe de râler, il faut quand même noter qu'à ma connaissance, aucun langage n'est conçu pour traiter correctement les dépendances, et refilent le bébé au compilo, qui le refile au builder, qui le refile au système. Genre
#include <gsl/gsl_vector.h>et démerde-toi pour que ça soit la bonne version dans le path. Et si c'est dans l'en-tête d'un .h d'une lib, bah c'est pareil, le système va automagiquement se démerder pour lier la version que le dev de la lib avait en tête.(selon les langages, il peut exister des hacks plus ou moins efficaces pour récupérer la version du module chargé, mais je trouve ça assez dingue que ça ne soit pas dans les briques de base).
[^] # Re: Maintenance
Posté par PR . Évalué à 2.
Ou alors tu fais des interface propres et pérennes. Ce qui est un effet de bord d’un bon travail de conception qui prend en compte la maintenance dès l’élaboration du projet.
Si changement d’API, changement de headers, avec phase de transition éventuelle (gérée dans le cadre d’une maintenance).
On rejoint le commentaire précédent…
Mort aux cons !
[^] # Re: Maintenance
Posté par gouttegd (site web personnel) . Évalué à 10.
Il ne suffit pas que les auteurs de bibliothèques fassent des interfaces propres et pérennes. Il faut encore que ceux qui les utilisent ne fassent pas n’importe quoi.
J’ai eu le cas récemment d’un projet Python qui annonçait (dans la clause
requiresde sonsetup.py) dépendre depyparsing==2.4.7.J’ai vérifié : il n’y a rien dans le code qui justifie d’exiger cette version plutôt qu’une autre. Pas d’utilisation d’une fonctionnalité qui aurait été introduite avec cette version ou au contraire qui aurait été supprimé des versions suivantes. En fait, le code fonctionne très bien avec PyParsing-3.0.9 (j’ai essayé).
J’ai l’impression qu’au moment de lister ses dépendances, le développeur s’est dit « c’est quoi la version de PyParsing que j’ai sur ma machine ? 2.4.7 ? bon ben on va dépendre de la version 2.4.7 alors, avec celle-là je sais que ça marche… »
[^] # Re: Maintenance
Posté par claudex . Évalué à 7.
Le problème, c'est que c'est compliqué de prévoir le futur. Tu as la version 2.4.7 qui fonctionne. Le jour où la 2.4.8 sors, il faut relancer tous le tests (et en avoir assez), et ça pour toutes les dépendances. Je comprends qu'un petit projet ne s'y aventure pas. En plus, tu as testé la 3.0.9 avec ton utilisation, si ça tombe, il y a un bug pour d'autres cas d'utilisation qui impose cette version.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Maintenance
Posté par gouttegd (site web personnel) . Évalué à 4.
Tu n’es pas obligé d’imposer pour autant une version précise.
Si tu es responsable d’un petit projet et que tes ressources sont limitées, tu peux très bien annoncer clairement la couleur dans le README, genre
(Personnellement je ne pense même pas que ce soit nécessaire, pour moi c’est implicite qu’un projet libre fonctionne en mode « best effort », je n’attends pas du développeur qu’il garantisse un fonctionnement parfait en toutes circonstances.)
pipne te laissera même pas installer une version [annoncée comme] incompatible¹.Qu’est-ce qui est préférable ?
¹ Parce que bon, moi dans ce cas j’hésite pas à aller éditer le
setup.pyà la truelle pour virer ce qui me dérange et pouvoir tester avec la version que j’ai sous la main, mais je doute fort que beaucoup se donnent cette peine…[^] # Re: Maintenance
Posté par groumly . Évalué à 8.
J’ai longtemps été partisan des versions ranges pour les dépendances. « Les fournisseurs n’ont qu’à faire du semver et ne pas peter leur libraire! ». J’en suis revenu, maintenant je pin tout.
C’est bien joli le semver, mais d’une part tout le monde n’est pas forcément d’accord sur la définition de breaking api change. Yen a qui comprennent pas le concept, ou s’en foutent. T’as des mecs (comme PR en dessous) qui dit “si on change un truc et ça pete chez toi c’est ta faute, fallait lire la doc”. C’est son droit, mais perso ça me fait une belle jambe, et j’ai autre chose à faire que de chasser une régression juste parce que quelqu’un a publié une nouvelle version.
Aussi, avoir un build reproductible, c’est bien. Très bien. Et pour finir, ça permet de documenter quelle version est sortie avec quelle version de dépendance directement dans le repo. Et ça, c’est très bien aussi.
Bref, les version ranges, ca a l’air cool en théorie, mais en pratique, la prudence l’emporte. Ton kilométrage ne sera pas forcément le même, rien n’est jamais absolu, tout ça, mais pinner par défaut, et faire une exception si besoin est, me parait être le meilleur compromis.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Maintenance
Posté par PR . Évalué à -10.
C’est tout le contraire que j’ai dit. Je garantis que ça ne pête pas (et je corrige si c’est le cas).
Par contre ce que je garantis est sur un périmètre délimité. Parce qu’un codeur c’est pas un dieu omnipotent qui va t’apporter le café, te cirer les pompes et te s**** la b***.
Mais bon, t’es bien dans la mentalité des c*** que je rencontre au taf’ qui se disent qu’ils vont remplacer leur incompétence ou leur absence de travail (ceux qui lisent pas la doc, sont aussi ceux qui ne l’écrivent pas ceci dit en passant…) par leur grande gueule (et accessoirement leur copinage avec le chef).
Puis c’est pratique quand on est presta’ de pas faire de doc, ça permet de tenir le client par les c*******… Et aux collègues de faire le rétro-ingeniering comme ça on pourra médire sur leur lenteur.
À bon entendeur !
Mort aux cons !
[^] # Re: Maintenance
Posté par groumly . Évalué à 8.
Tu vas commencer par baisser d’un ton. Tu peux pas encadrer tes collègues, tant pis pour toi, mais j’y suis pour rien, on a pas gardé les cochons ensembles.
Je te cite:
Le problème c’est que le périmètre que tu délimiteras sera toujours trop petit. Et quelqu’un devra en sortir. Et à ce moment là, il faudra bien faire quelque chose du scénario qui sort du périmètre.
Après, oui, ça va peter, ça sera la faute à personne, et donc à tout le monde. Mais d’une part, c’est pas très constructif de répondre ça, d’autre part, ça change pas grand chose au problème de base: j’ai pas envie de me peter une régression parce qu’une mise à jour a été faite dans mon dos. Donc je pin les versions.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Maintenance
Posté par arnaudus . Évalué à 5.
Et dans 10 ans, tu dépendras d'obscurs modules qui ont 10 ans? Qui ne seront peut-être même plus disponibles ailleurs que sur les gros disques des repositories pip ou conda? Quand tu auras une faille de sécurité corrigée dans le module M1, soit tu restes avec ton trou, soit tu mets à jour M1, qui va dépendre d'une version récente de M2, qui va dépendre d'une version récente de M3, et manque de bol, tu utilisais déja une version ancienne de M3. Du coup, il va te falloir deux versions de M3? Tu vas patcher M2 pour qu'il soit compatible avec ta version de M3?
Honnêtement, j'ai du mal à imaginer comment le pin de version est compatible avec la maintenance d'un logiciel. Ou alors tu pars du principe que ton truc sera obsolète d'ici quelques années, et qu'à ce moment tu réécriras tout from scratch avec des technologies plus récentes.
Ça doit évidemment dépendre de ce qu'on distribue, et à qui on le distribue. Mais je n'ose pas imaginer ce qui se passerait si Firefox par exemple décidait qu'il dépendait d'une version fixe de libcairo ou de libgtk. Tu seras bloqué toute ta vie avec une distrib de 2022? Tu pourras mettre à jour Firefox, mais aucune autre de ses dépendances?
[^] # Re: Maintenance
Posté par groumly . Évalué à 10.
Non, je les met à jour régulièrement. Mais quand je décide, et en planifiant du temps pour s’assurer que tout marche bien.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Maintenance
Posté par guppy . Évalué à 2.
Ouais en pratique c'est troué la plupart du temps donc…
Je suis assez d'accord avec ta critique sur les ranges, mais ta "solution" n'en est pas une non plus.
Le problème de fond c'est que les dépendances c'est chiant ; ça paraît génial au début (on va pas se faire chier à recoder ce qui existe déjà), mais ça implique qu'il faut les surveiller très régulièrement.
Ceci étant dit, je fais presque comme toi (à part que je les gère à la main), mais je suis conscient des limites de cette méthode.
[^] # Re: Maintenance
Posté par claudex . Évalué à 6.
C'est valable avec le code que tu écris aussi, sauf qu'il n'y a peut-être personne qui pense à le mettre à jour en cas de faille.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Maintenance
Posté par barmic 🦦 . Évalué à 8.
Non contrairement à ce que dit l'adage ton gestionnaire de version ne télécharge jamais la moitié de la planète. Le nombre de mises à jour de sécurité au sein d'un logiciel ne représente pas une quantité si folle. L'énorme majorité de tes mises à jour c'est juste le cycle de vie de ta dépendance, elle fix des bug, ajoute des fonctionnalités, mais n'a rien de connu en terme de sécurité et peu même t'en apporter. Regarde la fréquence de mise à jour de ta distribution qui a beaucoup beaucoup plus de code et donc de dépendance. Moi sur ma debian stable donc avec quasiment que des mises à jour de sécurité, j'en ai quelques unes par mois.
Ce qui est trivial puisque tu as un gestionnaire de version. Suivre les mises à jour de tes dépendances est vraiment quelque chose de simple et d'automatique. Lance le à la fréquence que tu veux. Pour la vérification de faille de sécurité (CVE mais pas que) c'est pas tout à fait aussi simple et ça a une tendance aux faux positifs qui c'est pas géré par ton gestionnaire de version, mais ça va il y a plus compliqué.
C'est aussi une bonne pratique de mettre à jour fréquemment pour ne pas être en mode big bang tous les 7 ans.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Maintenance
Posté par flagos . Évalué à 5. Dernière modification le 24 août 2022 à 10:30.
Je connais pas toutes les systèmes de gestion de dépendances, mais en principe, tu pars d'un fichier ou tu specifies tes contraintes, tu lances un update de l'env, ca te genere un .lock que tu versionnes, et tu fais ta build a partir de ce lock.
Donc a priori, pas de raison que ca pète en dehors du moment ou tu as choisi de faire un update du lock.
[^] # Re: Maintenance
Posté par freem . Évalué à 3.
C'est marrant ça. Parce que moi, quand j'écrivait de la doc (tout le temps quand j'était au taf, a divers niveaux de qualité en fonction de l'urgence et de la finition) c'était pour tout le monde, les autres, et moi.
Je préfère avoir une doc qui me permette de revenir 3 mois plus tard a un code que j'ai oublié parce qu'entre temps je suis passé sur 2 ou 3 autres sections du système, et très honnêtement, je sais pertinemment que pour de la doc, mieux vaut ne pas attendre après les autres…
Donc, si tu veux de la doc utile, c'est pas compliqué: tu te sors les doigts quand tu fais ton projet, tu commences par documenter l'archi du proto, puis tu code, puis tu mets à jour la doc. C'est p'tet pas agile, c'est pas non du plus du V, mais ça a très bien marché pour moi. Et quand un collègue venait me sortir qu'il avait trouvé un bug dans mon code, je demandais 2 choses: les logs, et 5 minutes pour qu'il me dise pourquoi il avais mal interprété la doc. Que je la mette à jour.
Alors, quand je parle de doc, hein, je parle pas de ces horreurs de fichiers word. Je parle d'un simple .txt posé dans le repo, et quand ça deviens trop massif, je le divise (typiquement: utilisation, déploiement et maintenance, déjà ça rend les choses plus simples).
Oui c'est moche le .txt, y'a pas de couleurs, pas de gras… mais on peut faire des paragraphes et des retours à la ligne sans se prendre la tête, on peut utiliser son éditeur de code préféré pour maintenir/visualiser, et ça se versionne super bien. Tant qu'on ne s'amuse pas trop a coller des URI à rallonge en brut dans le texte, mais ça de toute façon on peut pas y faire grand chose (enfin si: les mettre dans un index, mais de toute façon c'est rare que je colle des URIs longues dans une doc technique).
[^] # Re: Maintenance
Posté par Lutin . Évalué à 3.
Ça peut être agile, par exemple sur de l'agile à post-it on ne déplace un ticket dans la colonne "finis" que si la doc correspondante a été écrite.
À la place du .txt tu peux faire du latex, ça se versionne tout aussi bien.
[^] # Re: Maintenance
Posté par freem . Évalué à 3.
C'est ce que j'utilisais pour les documentations "read-only" pas techniques. Pour que ça soit plus joli. Au passé, parce que j'ai changé de métier et je n'ai plus ce besoin du coup, sinon LaTeX est effectivement mon outil préféré à l'heure actuelle, même si je m'en sers une fois tous les 36 du mois.
[^] # Re: Maintenance
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
J'utilise encore toujours du LaTeX pour faire des documents finaux léchés (y compris le PDF de mes courriers papier) tout en ayant un source textuel (pouvoir utiliser un éditeur de texte et ne pas attendre de devoir installer une appli et un environnement graphique est un plus pour moi) versionnable de surcroit.
Pour de la doc technique poussée, pour tout ce qui ne peut pas être du simple .txt je m'oriente vers du .rst ou .adoc (pitié pas de .md) ; mais il faut discuter avec l'équipe si un wiki n'est pas nécessaire et comment s'assurer de garder les choses synchro…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Maintenance
Posté par claudex . Évalué à 6.
Sauf que du coup, ça ne marche pas pour quelqu'un qui fait un simple
pip installde ton paquet, parce que ça va chercher la dernière version qui n'a pas été testée. Et perso, je n'ai pas envie de lire tous les readme de toutes les dépendance de mes dépendances pour trouver quelle version je dois pin parce que ça bug.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Maintenance
Posté par ff9097 . Évalué à 2.
Tu as testé tous les cas possibles ? Ou juste ceux que tu utilises et en fait : "ça a l'air d'aller" ?
[^] # Re: Maintenance
Posté par gouttegd (site web personnel) . Évalué à 5.
J’ai testé tous mes cas d’utilisation et toute la suite de tests fournis avec le projet lui-même. Pas une seule erreur, tous les tests passent. Pour faire bonne mesure je me suis même amusé à tester avec une version sortie trois ans plus tôt. RAS.
J’ai rien contre l’épinglage de versions précises quand il est justifié, mais ici, on est dans le cas typique d’un développeur qui a épinglé une version arbitraire juste parce qu’il ne voulait pas se casser la tête. (J’ai vérifié l’historique : la contrainte sur le numéro de version a été ajoutée en même temps que la dépendance elle-même — avant même que quelqu’un ait l’occasion de tester avec une autre version et de rapporter un comportement différent, qui aurait pu justifier l’épinglage.)
Je ne vois pas en quoi c’est si difficile à croire, vu qu’on a dans ce même fil des développeurs qui assument clairement faire la même chose — parce que hé ho, hein, bon.
[^] # Re: Maintenance
Posté par ff9097 . Évalué à 3.
Normalement seules les apps ont un fichier avec les versions des dépendances fixées. Je crois que pour les bibliothèques ce n'est pas conseillé. Je ne sais pas quel est ton cas.
[^] # Re: Maintenance
Posté par arnaudus . Évalué à 7.
Mouais. On peut aussi sortir des logiciels sans bugs, comme ça, plus besoin de bug trackers…
Tu peux toujours faire en sorte de ne pas casser les interfaces existantes, mais ça ne marche que dans un sens (on peut utiliser une lib récente sur un code ancien, mais pas le contraire). Il ne faut pas non plus qu'une politique de non-évolution trop stricte t'empêche d'améliorer l'interface.
Et puis, les problèmes de compatibilité peuvent arriver sans changement d'interface. Tu ne peux jamais prévoir comment les utilisateurs vont contourner les bugs; si dans ta version 1.0 tu avais sqrt(-2) qui renvoyait Inf, et que tu décides de corriger ça et de renvoyer NaN dans ta version 1.2, tu n'es pas à l'abri de flinguer le code d'un utilisateur qui testait
if (isinf(sqrt(foo)).[^] # Re: Maintenance
Posté par PR . Évalué à 2. Dernière modification le 23 août 2022 à 01:06.
D’où la documentation, la rigueur sur le périmètre couvert et ce qui n’est pas spécifié, etc.
Soit tu as spécifié que sqrt(-2) doit renvoyer NaN et tu t’y tiens, soit tu n’as rien spécifié du tout pour les nombres négatifs et si tu casses un code utilisateur, c’est sa merde pas la tienne.
Mais bon, c’est has been de travailler comme ça. La méthode gruik c’est tellement plus rapide…
Quand à rendre un résultat parfait, ce n’est pas le sujet : on écrit tous du code buggué, mais au moins les spécif. donnent une bonne base de discussion (et souvent d’argumentation, éventuellement un peu musclée…) pour savoir ce qui est erroné ou pas.
Et surtout pour savoir QUI doit corriger le bug ; je sais pas comment vous faites dans le monde pro avec une groses base de code à faire évoluer et à maintenir… (et pour la petite blague : quand vos utilisateurs sont plus que 1, pas d’accord entre eux, et prêt à s’écharper pour avoir le dernier mot…)
Mort aux cons !
[^] # Re: Maintenance
Posté par arnaudus . Évalué à 1.
Bah, c'est expliqué dans le journal : conda et/ou gros binaire monolithique, le développeur fournit une image de sa machine au client pour que le code tourne, et 10 ans après c'est toujours le même environnement.
[^] # Re: Maintenance
Posté par PR . Évalué à 2. Dernière modification le 23 août 2022 à 08:06.
Lol. Après ce genre de commentaire tu iras expliquer à Mme Michu qu’il faut mettre à jour son informatique pour la sécurité…
(tu travaillerais pas dans la boîte qui a vu ces 900 serveurs se faire hacké-rançonné par hasard ?)
Mort aux cons !
[^] # Re: Maintenance
Posté par arnaudus . Évalué à 10. Dernière modification le 23 août 2022 à 09:58.
C'était ironique, hein. Deux posts plus haut j'expliquais que ces pratiques de gestion des dépendances n'existaient pas quand on maintenait ses logiciels, mais pour ça il faut juste bosser. Si on ne fout rien pendant 10 ans, on a besoin de dépendances qui ont aussi 10 ans.
Je travaille dans la recherche publique, donc c'est bien pire que ça. Il arrive fréquemment qu'il n'y ait pas d'admin sys dans les laboratoires, tout le monde est root sur les serveurs, et les logiciels métier sont des trucs confidentiels codés par des stagiaires, utilisés par 3 personnes dans le monde et téléchargés sur un serveur chinois pas mis à jour depuis 7 ans.
J'imagine que le seul point fort des labos publics c'est que tout le monde sait qu'ils n'ont pas un rond et qu'il serait impossible même avec la meilleure volonté du monde de sortir une rançon de 10$ en bitcoins avec les règles de la comptabilité publique.
[^] # Re: Maintenance
Posté par PR . Évalué à 1.
Arf, désolé, difficile de déceler l’ironie à l’écrit et je regarde pas trop qui l’auteur.
Pour l’informatique dans la recherche, je connais j’ai été thésard
^^la problématique y est différente. L’utilisateur est le développeur, c’est du code plus ou moins “jetable”, constamment en évolution (propre à un travail de recherche), avec des enjeux très largement réduits (à l’inverse un hôpital s’est bien fait rançonner récemment, malgré tout).Ceci dit j’utilisais aussi à l’occasion du code plus professionnel, typiquement dans les librairies ou certains codes à vocation plus généraliste. Et c’est là où j’ai pu voir parmi les meilleurs sources qui m’ait été donné de lire : claires (malgré la complexité du sujet traité), maintenues, qui suivent des normes précises, API bien définie (c’est important dans un code scientifique). Ce genre de code faisait l’objet de publication (et donc d’une procédure de validation scientifique).
Mort aux cons !
[^] # Re: Maintenance
Posté par arnaudus . Évalué à 6.
Qui plus est, "amateur" (souvent aucune formation).
Mouais, enfin il faut être honnête : quelle est la proportion de résultats scientifiques publiés affectés par des bugs plus ou moins importants? Si c'est 80%, alors on est un peu payés pour rien. La qualité de la production scientifique, c'est maintenant avant tout la qualité et la reproductibilité du code pour l'analyse des données.
Certes, mais "jetable" ne veut pas forcément dire "crado". Dans ce contexte, la stabilité des API n'a aucun intérêt en effet (puisque par définition on fait tout le temps évoluer le code jusqu'à la publication, et le code ne tournera probablement plus jamais après); les optimisations prématurées sont proscrites, on ne code que ce dont on a besoin au moment où on en a besoin. Mais ça n'empêche pas de documenter un minimum (on peut être relu et on doit pouvoir justifier chaque bout de code), ça n'empêche pas d'utiliser un gestionnaire de version, etc.
Il est certain que les pratiques peuvent changer, et que ceux qui travaillent mieux peuvent s'en sortir. Mais ça dépend également des modes de financement (typiquement, il n'y a aucun financement possible pour la maintenance), des modes d'évaluation (est-ce que la qualité des logiciels est évaluée, est-ce qu'il est valorisable de contribuer à un projet libre, etc), et de la culture scientifique dans la discipline (valorisation du travail collectif vs. chacun dans son coin).
Une nouveauté de cette année, c'est le recrutement de "data editor" dans les journaux scientifiques (ceux des sociétés savantes hein, les grands éditeurs s'en fichent). Ils vont vérifier si les auteurs des articles mettent bien à disposition les données scientifiques et le code utilisé pour les analyses.
[^] # Re: Maintenance
Posté par freem . Évalué à 5.
Je pense que tu es au courant, mais certaines libs, genre les libs standard de C et de C++, ainsi que leurs variantes des divers compilateurs, définissent des symboles que l'on peut vérifier pour s'assurer d'avoir les fonctionnalités dont on a besoin.
Je ne dis pas que c'est parfait, mais je dirais que ça semble marcher, et peut-être que personne n'a rien trouvé de mieux, parce que le problème n'est pas trivial.
# Le peu de Python que je fais...
Posté par gUI (Mastodon) . Évalué à 6. Dernière modification le 22 août 2022 à 17:57.
… bin je trouve ça super pratique le
venv. Alors vu que j'ai une petite utilisation de Python (mais régulière), surtout perso, je dois peut-être louper les vrais soucis de "prod" ?Alors dans l'ordre :
dans quel environnement je suis : tu es dans celui que tu as explicitement demandé:
.venv/bin/activate. et oui, je trouve que mettre son nom dans le prompt est une bonne idée, déjà pour vérifier qu'on l'a bien activé. mais hors de question d'en mettre un par défaut dans le.bashrcpar exemple.comment j'en change : en en demandant un autre (c'est la même commande, mais ailleurs) ? ou en tuant l'xterm et en revenant au 1er point ?
qu'est-ce qu'il y a dedans :
pip freezeoucat requirement.txt. je fais attention à avoir toujours monrequirement.txtà jour (j'ai la commande de freeze dans mon Makefile)comment je le mets à jour : tu ne le mets pas à jour. sauf menace terroriste avérée. ou sinon si tu aimes les emmerdes, et que tu as une bonne couverture de tests, tu as un truc style
pip --upgrade(que je connais pas par coeur, je le fais quasiment jamais). Et si tu le mets à jour c'est package par package, avec une bonne raison (bugfix, security…). Mais pas "tiens, ça fait longtemps que j'ai pas upgradé… allons-y".J'ai tellement eu de soucis avec les packages Python avant d'utiliser systématiquement un
venvdédié à chaque projet que j'ai du mal à comprendre tes critiques.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Le peu de Python que je fais...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pour en changer, tu quittes l'actuel par
deactivatepuis t'en lances un autre.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Le peu de Python que je fais...
Posté par arnaudus . Évalué à 10.
C'est pas exactement le signe que ça tient avec des bouts de ficelle, ça? Tous les jours, ton environnement se décale par rapport aux versions maintenues des dépendances. Un jour, quelqu'un sous macOS va avoir un problème pour trouver la vielle version du module machin sur pip, il faudra 20 minutes pour installer l'environnement sur une Ubuntu récente, et puis peu à peu tout va devenir obsolète, certaines dépendances ne fonctionneront plus avec systemd, avec wayland, et paf, ça sera fini.
[^] # Re: Le peu de Python que je fais...
Posté par Dring . Évalué à 4.
A sa décharge, l'auteur du commentaire précédent précise que c'est un usage plus ou moins personnel. Mais c'est vrai que le coeur du problème est là : sans mise à jour régulière, le code devient obsolète, et le jour où on est forcé d'upgrader (problème de sécurité) c'est l'enfer.
Le problème a (enfin) été compris chez nous quand il y a eu la grosse vulnérabilité sur Struts il y a quelques mois. Découvrir qu'on avait encore une chiée d'application sur Struts 1.x, que pour passer à la bonne version de Struts 2.x ça prenait plusieurs semaines de taf car on avait plein d'autres dépendances qui suivaient, ça a donné des sueurs froides à tout le monde.
Mais le problème va rester : la plupart du temps, par négligence, oubli, incompétence ou volonté de montrer le chiffre le plus petit possible pour qu'il passe, on n'a pas de budget pour la non-obsolescence des dépendances d'un projet.
# IDE
Posté par Papey . Évalué à 5.
Personnellement avec PyCharm la bascule entre différents venv se fait juste en changeant la fenêtre active. Chaque fenêtre a son onglet de terminal qui déclenche automatiquement le venv du projet actif dans la fenêtre quand on l'active.
[^] # Re: IDE
Posté par PBellicano . Évalué à 4. Dernière modification le 23 août 2022 à 10:12.
Oui. J'ai tenté également. PyCharm semble/semblait vraiment très bien.
Malheureusement encore, après quelques essais pour intégrer des libs à ces venv (via Pycharm donc) (j'en avais crée plusieurs afin de tenter de reproduire un environnement un peu plus ancien semblable à celui du serveur) -> plantage (dissonance, incohérence, problèmes de dépendances et même segfault de je ne sais plus quel binaire). Bref, venv n'a pas rempli son rôle. Tenté sous osx…. Ben voilà.. Désolé mais j'ai fini par "tout" faire moi-même en php + C).
# Le problème vient des systèmes de gestions de dépendance, ou du nombre de dépendances ?
Posté par Wawet76 (site web personnel) . Évalué à 8.
J'ai l'impression que NPM marche plutôt bien, mais le nombre de dépendances dès qu'on importe le moindre truc me semble hallucinant.
Pour moi, ce problème ne vient pas de NPM mais de l'absence d'une bibliothèque standard bien foutue et bien gérée.
[^] # Re: Le problème vient des systèmes de gestions de dépendance, ou du nombre de dépendances ?
Posté par rewind (Mastodon) . Évalué à 10.
Je trouve ce commentaire très drôle. Parce que dans la communauté C++, on essaie de mettre de plus en plus de choses dans la bibliothèque standard, et le principal argument de ceux qui freinent cette tendance est de dire qu'il faudrait un bon gestionnaire de dépendances pour qu'on n'ait plus à tout mettre dans la bibliothèque standard.
# Ce que tu cherches s'appelle peut être ActiveState
Posté par Christophe B. (site web personnel) . Évalué à 4. Dernière modification le 23 août 2022 à 10:44.
Bonjour,
Cette discussion est intéressante et je voudrais juste ajouter une pierre a cette édifice
Ce que tu cherches : un environnement python avec des librairies stables et pérenne
Peut être qu'il s'agit de Active State
tout à un cout, même les produits gratuits …
python offre énormément de librairie et parfois cela déclenche des incompatibilité complexes
Soit tu peu les gérer toi même, soit tu attends que quelqu'un le fasse
Soit tu prend un produit comme ActiveState
Qui est pour python, ce que RedHat est pour Linux (enfin d'après ce que j'ai compris)
Le but n'est pas de faire de la pub pour ActiveState, mais juste de rappeller que l'environnement Opensource est riche en solutions, si tuas le temps et les compétence tu peu te débrouiller.
Ce qui n'est pas le cas d'un environnement propriétaire ou tu n 'as pas le choix
[^] # Re: Ce que tu cherches s'appelle peut être ActiveState
Posté par Dring . Évalué à 3.
Peux-tu aller un peu plus loin et expliquer en quoi ActiveState répond aux problèmes levés dans ce journal ? J'ai été voir la page d'accueil et je vois "Build your Python, Perl, Ruby, and Tcl dependencies from source" ce qui est très étrange pour des languages interprétés (même si oui, souvent une lib python critique en terme de perf va être accompagnée de libs natives optimisées).
Sur la page que tu as donné, il semble que ActiveState est lié à la génération des artifacts et des images docker, mais sans précision.
Alors c'est quoi exactement, ActiveState ? Un vérificateur de dépendance à la NexusIQ ? Un repo qui garantit de n'avoir que des dépendances vérifiée par un tiers de confiance ? De la poudre verte ? Autre chose ?
Ta phrase semble dire que c'est l'équivalent pour Python de ce qu'est RedHat pour Linux. Mais ça n'a pas vraiment l'air d'être une "distribution Python". Ou alors ils s'expriment d'une façon qui m'est totalement opaque. Et dans ce cas, en quoi/comment ça règle le problème des dépendances qui évoluent ?
[^] # Re: Ce que tu cherches s'appelle peut être ActiveState
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Pour l'avoir utilisé, dans Fenêtre et non Nux, ils font bien des distributions Python : quand ut veux par exemple pyA.B.C ça te permet d'avoir cette version avec quasiment toutes les libs associées compilées, et tu peux avoir plusieurs versions installées sur ton poste.
Il y a des mises à jour (donc les dépendances évoluent) dans la branche A.B.C de travail, sans que les installations se mélangent. (dans nombre de distributions Linux on a la même chose puisqu'on peut avoir plusieurs versions installées…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ce que tu cherches s'appelle peut être ActiveState
Posté par Dring . Évalué à 2.
J'ai pas fait de projet Python récemment, mais j'avais l'impression qu'on obtenait quelque chose d'assez proche avec les outils de base (pip + pip-tools). Et avec les environnements virtuels pour isoler chaque projet, tu évites de polluer le projet X avec les dépendances du projet Y.
Je vois toujours pas la plus-value de ActiveState.
[^] # Re: Ce que tu cherches s'appelle peut être ActiveState
Posté par Christophe B. (site web personnel) . Évalué à 5. Dernière modification le 25 août 2022 à 14:48.
C'est une réponse au "bazar" de l'open source (pas péjoratif ..)
Je viens de regarder leur site et je confirme pour 84$/mois ( 1008$/an )
tu as accès a du support sur leur version de python et un ensemble de librairie python revue et corrigé pour leur "environnement"
Cet environnement est gratuit mais ne permet que de faire des projets publics et ne dispose pas du support
C'est comme pour RedHat et linux ils "vendent" leur expertise sur un environnement avec du support et un environnement cohérent (et tu peu utiliser les sources)
La ou si tu compiles toi même python ou utilise la version de ubuntu 18 + pip pour installer les dernières versions de lib tu n'auras pas la "garantie" de la cohérence
Comme pour linux : si j'ai un environnement de TEST j'utilise Rocky/Centos mais sur l'environnement de PROD et de PRE PROD j'ai RedHat Linux avec du support
Si tu utilises python pour tes besoins perso 1008$/an c'est cher
Si tu utilises python dans un logiciel, et que ce logiciel tombe en rade, et que cela bloque 100 utilisateurs pendant 1 journée cela coute tres cher ( 100 x le cout journalier du smic = 7500 euros )
Si le support d'activestate te permet de résoudre le problème en 1h (meme si 100 x 1h horaire de smic c'est 1000€ environ) voire même t'évite le problème alors 1000$ par an c'est pas si cher que cela ( et encore je simplifie le problème )
Analyse du risque … comme se prémunir des risques "évitables"
Autre exemple d'actualité :
un hôpital choisit windows comme OS car Apple c'est trop cher jusqu'au jour ou …
# Un peu de tout
Posté par Julien Jorge (site web personnel) . Évalué à 3.
J'arrive un peu tard mais je participe quand même.
Sur mes petits projets il y a peu de dépendances et pas de conflit de versions. Je prend donc ce qui est disponible sur le système ou alors je compile et j'installe dans
~/.local/. Pendant un moment je m'embêtais à gérer dans mesCMakeLists.txtla possibilité d'utiliser la version locale ou de télécharger la dépendance viaFetchContent. C'était une très mauvaise idée, ça fait plein de cas à gérer et amène trop de questions. Du coup maintenant c'est seulement du local, beaucoup plus simple.Au boulot on a des tonnes et des tonnes de dépendances. Du coup on fait des RPM pour chaque, et je suis bien content de ne pas m'en occuper. Parmi les trucs qui m'embêtent il y a le problème que lorsqu'on modifie une dépendance il faut refaire les RPMs pour toute la chaîne jusqu'au produit pour pouvoir enfin tester, voir qu'on a oublié un truc, re-patcher la dépendance, et recommencer. L'autre souci est que ça devient tellement gros que ça bloque tout le monde sur une distribution donnée. Du coup si t'es sous Windows, ou sous un Linux non corporate, il te faut une VM Linux, ou un Docker, avec la distrib' officielle pour pouvoir travailler. C'est un vrai frein au quotidien, tous les outils deviennent dépassés hyper vite.
Avant ça dans une autre boîte sur un projet plus petit et une petite équipe j'avais pris une approche à base de script. Pour donner une idée de l'échelle, nous étions trois développeurs au maximum et il y avait une petite quarantaine de dépendances. En gros ça ressemblait à ça :
.localdu build. Les dépendances pouvaient être des bibliothèques ou des outils de build (par exemple le SDK Android). Les dépendances étaient récupérées au choix uniquement localement ou alors depuis un bucket S3. Il faut voir le dossier.localcomme un/dans lequel les dépendances étaient cherchées par le système de build./. D'autres dépendances étaient compilées, installées dans un dossier temporaire puis archivées pour être prêtes à être mises telles quelles dans le faux/.Dans les aspects bien pratiques :
bash,sed,grep,tar, et un compilateur pour lancer le tout, et encore ce dernier pouvait faire partie des dépendances).Dans les aspects pas pratiques :
De mon côté je n'ai jamais utilisé Conan ou vcpkg et je me demande si ces outils auraient permis d'installer des dépendances d'outils de build telles que le SDK Android ou autres outils. Ou encore de construire les dépendances à partir de dépôts locaux. Concernant l'intégration dans les outils de build, je ne vois pas trop comment on pourrait par exemple lancer CMake en ciblant Android tout en essayant de récupérer le SDK via Conan intégré à CMake. Ça se mort la queue. Pour moi l'installation des dépendances se fait forcément en amont de la configuration du build. Donc forcément il y a un peu de scripting.
# Go et la compilation en statique ...
Posté par Christophe B. (site web personnel) . Évalué à 5.
D'ailleurs c'est pas le golang qui a remis au gout du jour la compilation en statique ?
( corrigez moi si je me trompe )
l’exécutable est un peu plus gros mais comprend toutes les dépendances de librairie liées statiquement
Au moins l'installation se fait en copiant le binaire … c'est tout
OK cela ne correspond pas forcément à tout les cas de figures, mais a mon humble avis ce n'est pas si bête …
[^] # Re: Go et la compilation en statique ...
Posté par Arvil . Évalué à 2.
Go, alpine, appimage même si ce n'est pas vraiment du statique… j'en oublie probablement des tonnes
Le statique a ses problèmes aussi, et les ABI ne se limitent pas au linkage…
[^] # Re: Go et la compilation en statique ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Oui je connais les problèmes du statique mais parfois cela rend des services
Exemple :
avec le langage go j'avais pu ré écrire un utilitaire d'envoi de mail (l'éditeur n'avait pas le temps …)
Avantage : presque le même code pour Windows et Linux
Autre avantage : installation par copie du binaire compilé en statique (sur les 2 OS)
Mais tu as raison cela a ses limites et cet exemple est plus du bricolage que du vrai développement
# Tu as oublié "composer" pour PHP
Posté par Laurent Destailleur (site web personnel) . Évalué à 3. Dernière modification le 01 septembre 2022 à 14:52.
…ou l'art d'ajouter à ton projet 2 687 724 fichiers quand tu as juste besoin de 1 ou 2 classes d'une librairie, histoire d'être sur d'introduire des conflits d'autoload et au moins une vingtaines de bugs critiques de sécurité…
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
# Déjà résolu: avoir un garant/distributeur pour les paquets importants. Exemple: FSF pour Emacs
Posté par Legrego . Évalué à 1.
Il est possible de faire plus souple que Ubuntu/Debian, mais il faut quand même quelqu'un pour faire le travail.
Emacs a un système de paquets par hiérarchie (cathédrale ET bazar simultanément). Il y a les paquets stables, avec un mainteneur, centralisés, sûr, sans dépendances externes, et avec plusieurs propriétaires (la FSF en plus de l'auteur original), puis plusieurs niveaux de dégradations dans la qualité "garantie".
Cathédrale (les seuls configurés par défaut, environ 1000 paquets):
- paquets internes distribués avec emacs (transfert à la FSF), mis à jour uniquement avec une nouvelle version d'emacs
- paquet elpa GNU (transfert à la FSF)
- paquet elpa nonGNU (- de paperasses que le précédent)
- les paquets de niveau elpa n'utilisent que les paquets internes ou de niveaux elpa, donc pas dépendances externes.
Bazar:
- paquet melpa (communautaire, idem pip, npm, etc., environ 5000 paquets)
- paquet "straight", en direct d'un lien github
Et il est possible d'être dans plusieurs niveaux à la fois. C'est le cas de org-mode, qui est interne et elpa (m-a-j plus rapide que le cycle de emacs).
Dans les langages "modernes", personne ne veut faire ce travail de construction/évolution de la "bibliothèque standard" et c'est le nœud du problème.
# Erlang/Elixir, mix et Hex
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Je suis déçu, personne n'a tapé sur Erlang/Elixir :-) La solution recommandée (mais pas la seule possible) dans ce monde est d'avoir une copie intégrale de toutes les dépendances (l'outil mix gère tout cela et peut télécharger depuis le dépôt de paquetages Hex, ou directement depuis un dépôt git). Ainsi, chaque programme est sûr d'avoir tout comme il veut (on peut spécifier la version désirée de plusieurs façons), une fermeture au sens mathématique du terme. Par contre, pas pratique du tout pour les petits scripts quick-and-dirty, ni quand il s'agit de patcher une faille de sécurité sur un module utilisé par plusieurs projets.
Plutôt que « data scientist » vs. les autres, je dirais que la tendance actuelle est de privilégier le développeur plutôt que l'utilisateur ou l'administrateur système (hashtag lutte des classes). Je ne crois pas qu'il soit possible d'avoir une solution qui plaise à tout le monde et je déplore que des gens défendent telle ou telle solution en prétendant qu'elle est « plus simple » ou « plus pratique », sans dire pour qui.
# Dependencies pour Python et Conan
Posté par Stibb . Évalué à 2.
Alors, autant l'argument "c'est l'avenir tu dois intégrer une gestion de dépendance dans tes projets" est complètement stupide, autant ignorer complètement ces systèmes l'est presque tout autant.
Alors, personnellement, je suis tellement plus efficace et "fiable" depuis que j'ai appris à bien maîtriser Conan pour le C++ et Poetry pour Python (conda pour la datascience, mais ce n'est pas la même chose), que je ne pourrais plus m'en passer. Mais la pente est raide, il y a un défaut de stabilité et de fiabilité par exemple pour Python, qui casse régulièrement si on n'a pas freezé bien comme il faut. Il faut de la rigueur, et pas mal d'entre-aide (on a une communauté de Pythoniste au travail pour se partager les bonnes pratiques par exemple).
C'est vrai que tout seul, c'est un peu compliqué de tout suivre si on n'a pas les bons canaux.
Par contre je trouve que les languages mordernes comme Rust qui font du systèmes de dépendances un citoyen de premier niveau beaucoup plus efficace et fiable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.