Si tu lis tout les commentaires, tu verra que j'ai déjà évoqué cette idée de mainteneur qui créent le paquet pour leur distribution.
Tu verras aussi qu'il a été mentionné que ces derniers ne prendront le temps de le faire que pour les applications ayant déjà beaucoup d'utilisateurs. Tout le monde n'est pas Firefox ou vim.
Le premier arbre de commentaire est à propos de AppData, ProgramData, ProgramFiles, et le registre.
Je considère ces dossiers comme l'équivalent Windows des dossier XDG.
Comme je l'ai dit, ces problèmes d'intégrations existent aussi sous Linux, pas mal d'applications ne respectent pas XDG et foutent tout et n'importe quoi dans le $HOME.
Quand on voit le merdier que foutent les devs sous Fenêtre et Pomme…
T'as des exemples concrets à donner ? Sous Windows, chacune de mes applications a son propre dossier dans lequel elle mes ses dépendances (le fameux Program Files ou pour Scoop, $HOME/scoop/apps/<application>, ou pour Steam son dossier steamapps).
Je ne vois pas de quel merdier tu parles.
savoir l’intégrer proprement à un système est une autre chose qui ne s’improvise pas non plus.
On ne parle pas d'intégration ici, mais de distribution. Parce que le problème d'intégration au système, il est autant présent sous Windows, Mac et les distributions Linux/BSD.
Contrairement aux systèmes fermés, on ne te demande pas de considérer « chaque variante de » mais de confier aux mainteneurs des distributions.
J'ai pas dit le contraire. Cependant les mainteneurs des distributions, ils ont que 2 bras et 24h dans une journée. Si ton application n'est pas populaire, tu peux courir pour que quelqu'un fasse le travail. Et si tu veux simplifier la vie de tes utilisateurs, tu vas donc devoir le faire toi même.
Mais comme c'est impossible de satisfaire tout le monde, tu va faire un paquet pour Ubuntu, un pour Fedora, et les autres vont devoir se démerder.
Mais c’est trop dur, on veut refaire sa jungle façon Python
Le soucis que pose Snap et Flatpak, c'est qu'ils viennent s'ajouter au gestionnaire de paquets de la distribution (apt, yum, …). Cependant, il existe des distributions qui utilisent ces gestionnaires de paquets sans apt/yum/… Comme ElementaryOS en fait.
Quel est le problème ici ?
Comparer un gestionnaire de paquet qui embarque un runtime sur lequel les applications peuvent se reposer, peu importe la distribution, avec l'état de l'art de la gestion de paquet sous Python, c'est de la mauvaise foie. C'est comme comparer des patates et des tomates. C'est tout simplement pas la même chose, pas le même cas d'usage.
Sinon, au passage, il y en a qui se chargent de leur DEB/RPM en n’ayant qu’une seule variante générique ; et ce ne sont pas que de petits projets.
Montre les. Car déjà, rien qu'entre Debian et Ubuntu, les noms de paquets ne sont pas forcément les mêmes. Donc un DEB pour Debian ne va pas forcément fonctionner magiquement sous Ubuntu.
On n’est pas sorti de l’auberge si les gens qui disent aimer/défendre/faire du libre répandent de fausses informations.
Il ne faut pas confondre "avis avec lequel je suis en désaccord" et "fausse information".
Aussi, je n'ai jamais dit aimer/défendre/faire du libre. Et je n'ai jamais dit le contraire non plus. Cela n'a rien à voir avec le débat. Et c'est qui "on" dans l'histoire ?
De l'autre, pour beaucoup de logiciels bien implantés il me semblait que c'était plutôt les communautés des distributions qui se chargeaient du packaging, non?
Oui mais ici, l'auteur du post accuse les développeurs de le forcer à utiliser Snap, quand il devrait accuser les mainteneurs des distributions de ne pas fournir de paquets.
Pardon, que dis-je. Il devrait plutôt respecter l'esprit du libre et faire le paquet lui même !
Du point de vue du développeur, si je veux distribuer mon application sous Windows, un ZIP ça suffit, mais idéalement je génère un installeur *.msi.
Pour Mac, je fais un *.dmg et basta.
Pour Linux, je dois faire un *.deb pour chaque variante de Debian qui a décidé de nommer ses paquets différemment, un *.rpm pour chaque variante de RHEL, tester mon application sur chacune de ces distributions pour vérifier qu'elle est compatible avec les versions des libs présentes sur le système, etc.
Ou alors, je ne distribue pas mon application sur Linux et tu te démerdes. A la limite je veux bien te filer un *.tar.gz qui contient toutes les dépendances que tu va pouvoir extraire dans ton /opt.
Ah, tiens, c'est plus ou moins ce que Snap et Flatpak font? Me fournir un environnement commun cross-distribution pour que je puisse distribuer mon application au plus grand nombre sans me soucier des millions de distributions Linux qui existent ? Bon ok, je veux bien faire un paquet Snap ou Flatpak en plus, mais c'est vraiment parce que je suis gentil hein.
Il y a 20 ans, les gens aimaient bien se plaindre que les développeurs d'applications ne distribuaient pas un port pour Linux.
Maintenant, les gens aiment se plaindre quand les développeurs le font mais pas avec leur solution favorite.
Je crois qu'en fait, les gens aiment juste se plaindre.
Alors pas exactement. Tu as besoin d'un fichier shipp.json dans le dépôt que tu cible en tant que dépendance pour pouvoir le compiler.
Ce n'est pas un "build system", le fichier shipp.json indique la commande de build et install, donc tu peux utiliser ce que tu veux: CMake, Ninja, Meson, … D'ailleurs, Shipp est écrit en Rust, et son shipp.json indique la commande cargo build et cargo install, donc ce n'est pas limité à C/C++.
Dans mes projets C/C++ j'avais pour habitude d'utiliser CMake et de add_subdirectory un git submodule pour gérer mes dépendances directes. Pour les dépendances transitive, on se retrouve avec des nested git submodule, et de la duplication de build à tord et à travers, ça devient très vite un cauchemar.
La, shipp va aller git clone/git pull les répos qui vont bien dans .shipp/deps/<dep name> et les installer dans .shipp/dist. On se retrouve donc avec un dossier .shipp/dist qui a les dossiers include, lib, bin, share, etc… que tu peux utiliser pour configurer correctement les flags -I et -L de ton compilateur par exemple.
Shipp au final, c'est juste ça : récupérer les dépendances, utiliser leur build system sans avoir de la grosse plomberie a faire pour l'intégrer au tient, compiler tout ça et compiler ton projet avec ton propre build system aussi.
C'est plutôt "n'attend pas que ce soit complètement parfait pour push".
Par exemple, pour aitoolkit, il me manquait une suite de test et la documentation. J'ai généré tout ça avec l'aide de Github Copilot (qui après avoir analysé mon code a pu générer tout ça à coup de TAB).
Pour Gin (le générateur de site statique), je m'en sers pour le site de Letlang (que je dois publier). C'est juste que j'ai pas finalisé la doc au delà de quelques tutoriels (pas de doc d'API par exemple), je l'ai quand même publié, mais ça ne veut pas dire qu'il n'est pas maintenu.
En fait, c'est plein de petits projets qui n'ont pas besoin de nouvelle fonctionnalité toutes les 3min (cc écosystème JS), mais si on remonte un bug, je le corrigerai. Les dépôts que je ne maintient plus je les archives sur Github.
Et le succès de mon dépôt aitoolkit (plus de 300 github stars en moins d'une journée), c'est motivant. Cette petite pépite que pas mal de monde a aimé, elle était restée sur mon PC pendant 1 an et demi !!
J'avais fait cette lib pour répondre à un besoin personnel, et j'ai décidé de la publier même non finie au lieu de la laisser pourrir sur mon pc.
Pas mal de codebases n'autorisent pas C++20
C'est réellement pas mon problème. C++20 et C++23 apportent beaucoup de fonctionnalités très intéressante, je vois pas pourquoi je m'en priverais.
STL utilisée, et pour de mauvaises raisons en plus.
Tu as réussi a inférer mes raisons simplement en lisant le code ?
La raison c'est que je ne voulais aucune dépendance. Le langage de base me fournit tout ce dont j'ai besoin, je ne vois pas pourquoi j'irais chercher ailleurs.
Ce code utilise auto pour tout et n'importe quoi.
Oui, parce que l'inférence de type c'est bien.
Il y a des shared_ptr qui devraient vraiment être des unique_ptr, également.
Ca c'est le premier point ou je suis d'accord. Mais j'ai eu des problèmes avec unique_ptr:
std::initializer_list ne peut pas contenir de unique_ptr car quand on itère dessus, cela fait une copie
je ne peux pas initialiser un std::vector de unique_ptr pour la même raison, car le constructeur utilise std::initializer_list
Cela m'obligerait donc a créer le std::vector, faire des push_back avec std::move, et ensuite std::move le std::vector au constructeur qui en a besoin, chiant.
Alors oui, j'ai pris l'option de facilité, utiliser shared_ptr, ça marche bien.
aucun outil.
Libre à toi de faire une PR, c'est ça aussi l'opensource.
J'ai initialement choisi Hugo, mais parce que je ne pouvais pas lui filer ma propre grammaire TexMate pour coloriser le code Letlang, j'ai d'abord utilisé Shiki côté client (qui donc parse le code et ajoute le style CSS côté client), pour ensuite faire Gin qui utilise Shiki directement côté "serveur".
Quand je dis "la coloration se fait à la compilation" je parle de parser le bloc de code pour le transformer en <pre><code>...</code></pre> avec plein de <span style="...">...</span>. Bien évidemment le rendu final est fait par le navigateur.
Pas sur d'avoir compris la question, avec Gin, je fais la colorisation syntaxique à la compilation justement, la ou avec Hugo je devais le faire côté client.
En vertu de la bonne foie, ou dans cette phrase est il mentionné que Napoléon a été pillé ?
Il a été offert ok, mais bel est bien déplacé jusque Paris. Ou est l'énormité ici ? Ou est la justification pour tant d'aggressivité envers un commentaire explicitement humoristique ?
On a même le module dis qui ne semble pas utilisé par contre.
En regardant tout ça d'un peu plus près, cela me semble très spécifique à CPython. Quid de PyPy, Jython (JVM), et autres implémentations ?
Je n'irai pas jusqu'à dire que c'est un gros hack, car cela exploite les détails d'implémentations "interne" de CPython, mais je n'irai pas jusqu'à dire que c'est "prévu". C'est "permis" me semble un bon compromis.
En tout cas, si je comprends bien le code, il vont en chier pour assurer la compatibilité lors des montées de versions de l'implémentation, car rien ne garantie qu'elle ne bougera pas.
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 2. Dernière modification le 29 janvier 2024 à 14:56.
Si tu lis tout les commentaires, tu verra que j'ai déjà évoqué cette idée de mainteneur qui créent le paquet pour leur distribution.
Tu verras aussi qu'il a été mentionné que ces derniers ne prendront le temps de le faire que pour les applications ayant déjà beaucoup d'utilisateurs. Tout le monde n'est pas Firefox ou vim.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 4.
Deux de mes choses favorites dans la vie, réunie en un seul miracle ?
Merci.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pas tous libre
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 5. Dernière modification le 29 janvier 2024 à 14:38.
https://github.com/freetocompute/kebe
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Someone is wrong on the internet
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 10. Dernière modification le 28 janvier 2024 à 23:17.
Vous commencez à casser les pieds avec votre discussion de sourd.
Personne ne contredit que le client est libre. Mais le système qui englobe le client et le serveur ne l'est pas, car le serveur ne l'est pas.
Oracle n'est pas libre, même si il existe des clients oracle libres.
Snap, qui inclus Snap Store n'est pas libre, même si il existe des clients pour le Snap Store qui sont libres.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 3.
Le premier arbre de commentaire est à propos de
AppData,ProgramData,ProgramFiles, et le registre.Je considère ces dossiers comme l'équivalent Windows des dossier XDG.
Comme je l'ai dit, ces problèmes d'intégrations existent aussi sous Linux, pas mal d'applications ne respectent pas XDG et foutent tout et n'importe quoi dans le
$HOME.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 2.
Pardonne mon ignorance mais, comment font-ils pour gérer les dépendances dont les noms diffèrent ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 5.
T'as des exemples concrets à donner ? Sous Windows, chacune de mes applications a son propre dossier dans lequel elle mes ses dépendances (le fameux
Program Filesou pour Scoop,$HOME/scoop/apps/<application>, ou pour Steam son dossiersteamapps).Je ne vois pas de quel merdier tu parles.
On ne parle pas d'intégration ici, mais de distribution. Parce que le problème d'intégration au système, il est autant présent sous Windows, Mac et les distributions Linux/BSD.
J'ai pas dit le contraire. Cependant les mainteneurs des distributions, ils ont que 2 bras et 24h dans une journée. Si ton application n'est pas populaire, tu peux courir pour que quelqu'un fasse le travail. Et si tu veux simplifier la vie de tes utilisateurs, tu vas donc devoir le faire toi même.
Mais comme c'est impossible de satisfaire tout le monde, tu va faire un paquet pour Ubuntu, un pour Fedora, et les autres vont devoir se démerder.
Le soucis que pose Snap et Flatpak, c'est qu'ils viennent s'ajouter au gestionnaire de paquets de la distribution (apt, yum, …). Cependant, il existe des distributions qui utilisent ces gestionnaires de paquets sans apt/yum/… Comme ElementaryOS en fait.
Quel est le problème ici ?
Comparer un gestionnaire de paquet qui embarque un runtime sur lequel les applications peuvent se reposer, peu importe la distribution, avec l'état de l'art de la gestion de paquet sous Python, c'est de la mauvaise foie. C'est comme comparer des patates et des tomates. C'est tout simplement pas la même chose, pas le même cas d'usage.
Montre les. Car déjà, rien qu'entre Debian et Ubuntu, les noms de paquets ne sont pas forcément les mêmes. Donc un DEB pour Debian ne va pas forcément fonctionner magiquement sous Ubuntu.
Il ne faut pas confondre "avis avec lequel je suis en désaccord" et "fausse information".
Aussi, je n'ai jamais dit aimer/défendre/faire du libre. Et je n'ai jamais dit le contraire non plus. Cela n'a rien à voir avec le débat. Et c'est qui "on" dans l'histoire ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 3.
Sur Windows, j'utilise Scoop
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 8. Dernière modification le 28 janvier 2024 à 14:35.
Oui mais ici, l'auteur du post accuse les développeurs de le forcer à utiliser Snap, quand il devrait accuser les mainteneurs des distributions de ne pas fournir de paquets.
Pardon, que dis-je. Il devrait plutôt respecter l'esprit du libre et faire le paquet lui même !
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# J'aimerais qu'on me considère en tant que tel
Posté par David Delassus (site web personnel) . En réponse au journal snap : de pire en pire.. Évalué à 10.
Du point de vue du développeur, si je veux distribuer mon application sous Windows, un ZIP ça suffit, mais idéalement je génère un installeur
*.msi.Pour Mac, je fais un
*.dmget basta.Pour Linux, je dois faire un
*.debpour chaque variante de Debian qui a décidé de nommer ses paquets différemment, un*.rpmpour chaque variante de RHEL, tester mon application sur chacune de ces distributions pour vérifier qu'elle est compatible avec les versions des libs présentes sur le système, etc.Ou alors, je ne distribue pas mon application sur Linux et tu te démerdes. A la limite je veux bien te filer un
*.tar.gzqui contient toutes les dépendances que tu va pouvoir extraire dans ton/opt.Ah, tiens, c'est plus ou moins ce que Snap et Flatpak font? Me fournir un environnement commun cross-distribution pour que je puisse distribuer mon application au plus grand nombre sans me soucier des millions de distributions Linux qui existent ? Bon ok, je veux bien faire un paquet Snap ou Flatpak en plus, mais c'est vraiment parce que je suis gentil hein.
Il y a 20 ans, les gens aimaient bien se plaindre que les développeurs d'applications ne distribuaient pas un port pour Linux.
Maintenant, les gens aiment se plaindre quand les développeurs le font mais pas avec leur solution favorite.
Je crois qu'en fait, les gens aiment juste se plaindre.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Question ?
Posté par David Delassus (site web personnel) . En réponse au lien shipp: Deadly simple package manager for your C/C++ projects, written in Rust. Évalué à 2.
Alors pas exactement. Tu as besoin d'un fichier
shipp.jsondans le dépôt que tu cible en tant que dépendance pour pouvoir le compiler.Ce n'est pas un "build system", le fichier
shipp.jsonindique la commande de build et install, donc tu peux utiliser ce que tu veux: CMake, Ninja, Meson, … D'ailleurs, Shipp est écrit en Rust, et sonshipp.jsonindique la commandecargo buildetcargo install, donc ce n'est pas limité à C/C++.Dans mes projets C/C++ j'avais pour habitude d'utiliser CMake et de
add_subdirectoryun git submodule pour gérer mes dépendances directes. Pour les dépendances transitive, on se retrouve avec des nested git submodule, et de la duplication de build à tord et à travers, ça devient très vite un cauchemar.La, shipp va aller git clone/git pull les répos qui vont bien dans
.shipp/deps/<dep name>et les installer dans.shipp/dist. On se retrouve donc avec un dossier.shipp/distqui a les dossiersinclude,lib,bin,share, etc… que tu peux utiliser pour configurer correctement les flags-Iet-Lde ton compilateur par exemple.Shipp au final, c'est juste ça : récupérer les dépendances, utiliser leur build system sans avoir de la grosse plomberie a faire pour l'intégrer au tient, compiler tout ça et compiler ton projet avec ton propre build system aussi.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Petit joueur
Posté par David Delassus (site web personnel) . En réponse au journal Combattre la procrastination en publiant mes travaux non finis. Évalué à 3. Dernière modification le 19 janvier 2024 à 21:49.
Ça, c'est la procrastination de vengeance à l'heure du coucher.
cf: https://fr.wikipedia.org/wiki/Procrastination_du_sommeil
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: désolé de faire le méchant
Posté par David Delassus (site web personnel) . En réponse au journal Combattre la procrastination en publiant mes travaux non finis. Évalué à 10.
Alors, pour le coup, c'est pas "push and forget".
C'est plutôt "n'attend pas que ce soit complètement parfait pour push".
Par exemple, pour aitoolkit, il me manquait une suite de test et la documentation. J'ai généré tout ça avec l'aide de Github Copilot (qui après avoir analysé mon code a pu générer tout ça à coup de TAB).
Pour Gin (le générateur de site statique), je m'en sers pour le site de Letlang (que je dois publier). C'est juste que j'ai pas finalisé la doc au delà de quelques tutoriels (pas de doc d'API par exemple), je l'ai quand même publié, mais ça ne veut pas dire qu'il n'est pas maintenu.
En fait, c'est plein de petits projets qui n'ont pas besoin de nouvelle fonctionnalité toutes les 3min (cc écosystème JS), mais si on remonte un bug, je le corrigerai. Les dépôts que je ne maintient plus je les archives sur Github.
Et le succès de mon dépôt aitoolkit (plus de 300 github stars en moins d'une journée), c'est motivant. Cette petite pépite que pas mal de monde a aimé, elle était restée sur mon PC pendant 1 an et demi !!
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Bof
Posté par David Delassus (site web personnel) . En réponse au lien AI Toolkit, donnez un cerveau à vos NPCs, une librairie C++ header-only. Évalué à 5. Dernière modification le 11 janvier 2024 à 22:26.
J'avais fait cette lib pour répondre à un besoin personnel, et j'ai décidé de la publier même non finie au lieu de la laisser pourrir sur mon pc.
C'est réellement pas mon problème. C++20 et C++23 apportent beaucoup de fonctionnalités très intéressante, je vois pas pourquoi je m'en priverais.
Tu as réussi a inférer mes raisons simplement en lisant le code ?
La raison c'est que je ne voulais aucune dépendance. Le langage de base me fournit tout ce dont j'ai besoin, je ne vois pas pourquoi j'irais chercher ailleurs.
Oui, parce que l'inférence de type c'est bien.
Ca c'est le premier point ou je suis d'accord. Mais j'ai eu des problèmes avec unique_ptr:
Cela m'obligerait donc a créer le std::vector, faire des
push_backavecstd::move, et ensuite std::move le std::vector au constructeur qui en a besoin, chiant.Alors oui, j'ai pris l'option de facilité, utiliser shared_ptr, ça marche bien.
Libre à toi de faire une PR, c'est ça aussi l'opensource.
Et pour finir :
C'est bien, personne ne t'oblige à l'utiliser.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: merci pour la découverte…
Posté par David Delassus (site web personnel) . En réponse au lien Encore un autre générateur de site statique, mais pour les développeurs de langage de programmation. Évalué à 2.
Ah oui je me suis peut être mal exprimé.
J'ai initialement choisi Hugo, mais parce que je ne pouvais pas lui filer ma propre grammaire TexMate pour coloriser le code Letlang, j'ai d'abord utilisé Shiki côté client (qui donc parse le code et ajoute le style CSS côté client), pour ensuite faire Gin qui utilise Shiki directement côté "serveur".
Quand je dis "la coloration se fait à la compilation" je parle de parser le bloc de code pour le transformer en
<pre><code>...</code></pre>avec plein de<span style="...">...</span>. Bien évidemment le rendu final est fait par le navigateur.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: sans tracker medium
Posté par David Delassus (site web personnel) . En réponse au lien Encore un autre générateur de site statique, mais pour les développeurs de langage de programmation. Évalué à 2.
En plus l'article est pas complet :(
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: merci pour la découverte…
Posté par David Delassus (site web personnel) . En réponse au lien Encore un autre générateur de site statique, mais pour les développeurs de langage de programmation. Évalué à 2.
Pas sur d'avoir compris la question, avec Gin, je fais la colorisation syntaxique à la compilation justement, la ou avec Hugo je devais le faire côté client.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: sans tracker medium
Posté par David Delassus (site web personnel) . En réponse au lien Encore un autre générateur de site statique, mais pour les développeurs de langage de programmation. Évalué à 2.
C'est pas un tracker, c'est un token d'authent pour bypasser le paywall pour ceux qui ne sont pas membre sur Medium.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Openigiri
Posté par David Delassus (site web personnel) . En réponse au lien Nouveau fork d'outils Hashicorp: après OpenTofu pour Terraform, OpenBao pour Vault. Évalué à 4.
Puisqu'on fork les outils d'Hashicorp avec des noms de plats japonais, je propose de forker Consul avec le nom "Openigiri".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: oui c'est la foire.
Posté par David Delassus (site web personnel) . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 5.
Dans l'espoir de pas la réinventer (la roue) :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: donc on doit utiliser quoi ?
Posté par David Delassus (site web personnel) . En réponse au lien .io considered harmful. Évalué à 1.
C'est vraiment de la mauvaise foi ça. Surtout après lecture des réponses suivantes.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: donc on doit utiliser quoi ?
Posté par David Delassus (site web personnel) . En réponse au lien .io considered harmful. Évalué à 1.
On moinsse l'humour et on plussoie la condescendance maintenant sur LinuxFR ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Précision
Posté par David Delassus (site web personnel) . En réponse au lien Face aux vols, le British Museum va numériser toutes ses collections pour un coût de 12,1 millions $. Évalué à 8. Dernière modification le 22 octobre 2023 à 20:59.
En vertu de la bonne foie, ou dans cette phrase est il mentionné que Napoléon a été pillé ?
Il a été offert ok, mais bel est bien déplacé jusque Paris. Ou est l'énormité ici ? Ou est la justification pour tant d'aggressivité envers un commentaire explicitement humoristique ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Précision
Posté par David Delassus (site web personnel) . En réponse au lien Face aux vols, le British Museum va numériser toutes ses collections pour un coût de 12,1 millions $. Évalué à 10.
Pourquoi les pyramides sont en Egypte ?
…
…
…
Parce qu'il n'y a pas la place au British Museum.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Curieux
Posté par David Delassus (site web personnel) . En réponse au lien Pony is a Python ORM with beautiful query syntax. Évalué à 3.
On va dire que c'est permis par CPython :
decompile(x)de ponyorm, notamment la ligne :codeobject = x.gi_frame.f_codeopcodede CPythonastde PythonOn a même le module
disqui ne semble pas utilisé par contre.En regardant tout ça d'un peu plus près, cela me semble très spécifique à CPython. Quid de PyPy, Jython (JVM), et autres implémentations ?
Je n'irai pas jusqu'à dire que c'est un gros hack, car cela exploite les détails d'implémentations "interne" de CPython, mais je n'irai pas jusqu'à dire que c'est "prévu". C'est "permis" me semble un bon compromis.
En tout cas, si je comprends bien le code, il vont en chier pour assurer la compatibilité lors des montées de versions de l'implémentation, car rien ne garantie qu'elle ne bougera pas.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg