jeanas a écrit 74 commentaires

Petite précision : Rye utilise Hatchling (le build backend de Hatch) par défaut. Mais il peut marcher avec n'importe quel build backend déclaré dans la table [build-system], de même que Hatch et PDM — mais pas Poetry, qui doit toujours être utilisé avec le backend de Poetry.

Pour un projet en C++, je pense que le mieux de très loin à l'heure actuelle est de prendre un build backend spécialisé, comme meson-python pour Meson ou bien scikit-build pour CMake.

Attention, au nom trompeur de PyInstaller, ce truc génère un .exe , pas un installeur. Le paragraphe de la dépêche est un peu ambigu sur le sujet.

Exact, merci pour la rectification.

Une petite blagues des environnement virtuels quand vous faites du code portable, c'est qu'ils ne s'activent pas de la même façon sous Linux et sous Windows. Ce serait trop simple, il était essentiel de changer \bin ou /scripts pour passer de l'un à l'autre.

Pas faux ; cela dit, de toute façon, l'activation doit être différente, vu qu'il faut un source d'un côté et pas de l'autre, comme les shells ne sont pas les mêmes.

(Apparemment, l'auteur d'origine de virtualenv est d'accord sur le fait que c'était une mauvaise décision, mais la casse de compatibilité si c'était changé aujourd'hui serait monumentale.)

Autre blague des projets portables, les "lock file" qui peuvent ne pas être identiques sous Windows et sous Linux (dependance à mariadb par exemple), sauf que c'est absolument pas géré par le format ni par les outils. C'est juste la m***** en fait.

Qu'est-ce que tu entends par « ne peuvent pas être identiques » ? C'est vrai que les paquets peuvent déclarer des dépendances dépendant de l'OS (et heureusement), et c'est vrai que pip-tools ne permet pas de créer un lock file unique pour toutes les plateformes, mais par contre Poetry le fait toujours, et PDM le fait par défaut.

Oui, j'aurais pu le mettre dans la liste, mais la longueur de la dépêche était déjà trop délirante. J'étais très enthousiaste pour Rye au début car c'était le seul capable de gérer les versions de Python (avec des exécutables précompilés, pas comme pyenv), mais depuis que Hatch a cette fonctionnalité, je suis moins chaud, car Hatch est beaucoup plus mature, même s'il manque encore les lock files à Hatch (pas pour longtemps, espérons-le).

Intéressant retour.

Mais l'évolution du langage qui n'est pas rétrocompatible et qui casse donc toute la base de code de la version précédente, ça, c'est mal.

À la décharge de Python, il y a eu pas mal d'efforts pour améliorer la rétrocompatibilité sur les versions récentes, notamment suite au traumatisme de Python 3 (exemple, autre exemple).

Alors il faut les faire tourner dans un venv séparé et donc les faire communiquer via de l'IPC système. Déjà que Python c'est lent, là, c'est carrément dément.

Je n'ai jamais eu ce cas, mais je suis d'accord que si c'est nécessaire, c'est assez dément.

Si au moins python faisait comme tous les autres langages de programmation (c'est à dire de supporter nativement du FFI)

Je ne comprends pas. ctypes n'est pas un support natif de FFI ? Ni la C API de CPython ?

De manière générale, une grande force de Python aujourd'hui (p.ex. dans les sciences) par rapport à d'autres langages est de pouvoir être mélangé assez facilement à du C, Rust voire même C++, et c'est justement ce qui complique énormément le packaging, comme j'essaierai de l'expliquer dans la prochaine dépêche, donc je ne crois pas qu'on puisse l'accuser de manque de support FFI…

Je fini par le leur signaler et l'on me réponds : Veuillez vider tous les caches de votre navigateur… Je n'avais aucune envie de perdre toutes les connexions de toutes mes sessions web, tous les "J'accepte les cookies", dire non à tous les "Acceptez vous les notifications push?"…

Je ne sais pas si Chrome a un équivalent, mais dans Firefox, il est très facile de ne supprimer que les cookies et le local storage d'un seul site donné sans toucher aux autres.

Et en python, ne pas avoir d'opérateur ternaire pour un language qui se veut lisible, quand on parle du non sujet des concours de C illisible, c'est ce que j'appelle un sacré manque. Et un manque total de cohérence pour vous.

Euh…

https://docs.python.org/3.12/reference/expressions.html#conditional-expressions ?

Je ne connaissais pas cette commande. Elle n'est pas installée sur ma machine…

Essaie de l'installer, elle sera probablement dans le paquet pwgen. Sous Debian ou dérivés (comme Ubuntu), ça devrait être sudo apt install pwgen, sous Fedora, sudo dnf install pwgen, …

J'avais vu mais ça ne marche pas :-(

PourMoiÇaMarche® ¯_(ツ)_/¯

_get_random()
{
local char_set
local symbol

symbol="$1"
char_set="$2"

printf "%s\n" "The generated password is :"
strings --bytes=1 < /dev/urandom | tr --delete --complement "{$symbol}" | head --bytes="{LENGHT}" | xargs --null
printf "%s\n" "The password entropy is : (_entropy{char_set}) bits."
}

J'ai écrit un script générant une chaîne de caractères de longueur et complexité variable selon les besoins, histoire de faciliter la génération de login/password pour les services accessibles sur Internet.

Première question : tu ne peux pas utiliser la commande pwgen ?

PS : j'ai du mal avec la mise en page du code, il y a le ${symbol} qui a merdé.

Le code se met dans un bloc encadré par ```. N'hésite pas à utiliser l'aide-mémoire Markdown qui s'affiche en-dessous de la fenêtre de rédaction.

Pourquoi conda serait plus adapté pour le packet wheel ?

Il y a un malentendu : les wheels sont un format qui n'est pas utilisé par Conda, car Conda a son propre format.

Conda est plus adapté pour distribuer du code précompilé, et ça, j'en reparlerai dans la troisième dépêche.

Et pourquoi appeler ça wheel ?

C'est encore une référence aux Monty Python…

https://stackoverflow.com/questions/21113163/wheel-is-a-reference-to-the-other-python

"Wheel" veut dire "roue" mais aussi "meule (de fromage)", et le PyPI est surnommé « cheese shop » d'après le titre d'un sketch des Monty Python, d'où les wheels qu'on récupère au cheese shop.

Note que le problème a déjà été réglé (https://lists.sr.ht/~lioploum/offpunk-devel/%3C4bf5c83950eb5a7f81007b1c6cea15db3e7c0d60.camel%40abou-samra.fr%3E, https://lists.sr.ht/~lioploum/offpunk-devel/%3C169944083399.7.17262020890421882748.208639390%40ploum.eu%3E). Il avait bien compris comment définir les entry points console_scripts, simplement il utilisait Flit, qui ne permet pas d'avoir plusieurs fichiers .py à la racine (il force à avoir soit un seul fichier .py, soit un seul dossier/package avec des fichiers .py dedans).

J'ai posté une suggestion sur la ML du projet.

Euh… Il y a aussi un Python système sous Linux et les gens peuvent se débrouiller pour installer des versions qui ne viennent pas de leur dépôt (et notamment avec Homebrew)

Oui, bien sûr. Simplement, il me semble qu'il est moins fréquent d'installer des Python qui ne viennent pas de la distribution. Mais il y a de la confusion sous Linux aussi.

Sinon, pour les dernières version de MacOS, il n’y a plus de Python et d’autres fournis par Apple…

Je ne suis absolument pas compétent pour macOS, mais de ce que je comprends de l'affaire, le Python qui a été supprimé est un Python 2. Apparemment, il y a encore un Python 3 qui n'est pas préinstallé par défaut mais vient avec les outils en ligne de commande XCode (ensemble qui comprend aussi clang, me semble-t-il). Il y a aussi le Python de Homebrew, le Python de son concurrent MacPorts, et le Python de l'installeur à télécharger sur python.org.

En tous cas, c'est ce que je comprends d'une recherche et notamment de cet article récent : https://www.jcchouinard.com/install-python-on-macos/ . Mais je me trompe peut-être complètement.

Pour ça aussi, il y a le XKCD qui va bien ☺

On m'a signalé qu'il ne faut pas dire « pallier aux limitations » mais bien « pallier les limitations » (et même chose pour « pallier aux lacunes »). Est-ce qu'un modérateur voudrait bien corriger ? Merci !

J'en parlerai plus en détail dans la deuxième dépêche ☺

En soi, il n'y a rien de très compliqué avec les environnements virtuels. Leur raison d'être essentielle, c'est de pouvoir utiliser et/ou développer le projet foo et le projet bar avec les dépendances des deux installées, sans qu'elles rentrent en conflit entre elles, ni d'ailleurs en conflit avec des outils écrits en Python de ta distribution Linux.

Et pour les utiliser, il y a juste quelques commandes à mémoriser :

# Crée un environnement dans <dossier-environnement>
python -m venv <dossier-environnement>

# Lance le Python de l'environnement, qui est isolé (il n'a pas
# accès aux paquets installés système, seulement à la bibliothèque standard)
<dossier-environnement>/bin/python 

# Installe des paquets dans l'environnement
<dossier-environnement>/bin/pip install numpy scipy pycowsay

# Lance une commande installée dans l'environnement par pip
<dossier-environnement>/bin/pycowsay meuh

# "Active" l'environnement en ajoutant son dossier bin/ au début du $PATH
# du shell.
source <dossier-environnement>/bin/activate

# Quand l'environnement est activé, on peut travailler plus agréablement :

python # équivalent à <dossier-environnement>/bin/python
pip # équivalent à <dossier-environnement>/bin/pip
pycowsay # équivalent à <dossier-environnement>/bin/pycowsay

# Désactive l'environnement
deactivate

# Supprime l'environnement
rm -rf <dossier-environnement>

Là où ça se complique, ce sont les plutôt « bonnes pratiques » avec les environnements, parce qu'elles ne sont pas vraiment standardisées. Il y a beaucoup d'outils qui gèrent des environnements à ta place (pipx, tox, nox, hatch, poetry, pour n'en citer que quelques uns).

Exemple de confusion : les gens entendent qu'il ne faut pas installer un paquet en dehors d'un environnement virtuel (c'est vrai), ils voient que pycowsay s'installe avec pipx install pycowsay (c'est correct), et ils en déduisent qu'il faut faire ça dans un environnement virtuel (c'est faux, parce que justement, l'intérêt de pipx par rapport à pip, c'est qu'il crée l'environnement tout seul).

Un autre problème pour les débutants, c'est qu'il faut déjà savoir comment invoquer Python : avec python ou python3 sous Linux (sachant que jusqu'à récemment, python pouvait être Python 2), et avec py sous Windows. Et sous macOS, c'est encore pire vu qu'il y a un Python système, mais aussi pour beaucoup un Python de Homebrew. Même chose avec le source <dossier-environnement>/bin/activate, qui dépend du shell (cette commande marche sous Bash et zsh, pour Powershell ce serait <dossier>\Scripts\Activate.ps1).

Autre source de confusion : la manière d'installer venv. Sous macOS et Windows, il vient préinstallé, mais certaines distributions Linux ne le mettent pas dans le paquet python pour réduire sa taille. Par exemple, sous Ubuntu, il faut faire sudo apt install python3-venv. Sans compter que certains préfèrent utiliser le module virtualenv au lieu de venv.

Bref, comme pour beaucoup de choses dans toute cette affaire, il n'y a vraiment rien de compliqué, mais les gens n'y comprennent rien parce que c'est vraiment difficile de donner des instructions qui marchent pour tout le monde sur tous les systèmes et avec tous les outils.

Ho, attention, le post en question n'est pas daté, mais d'après le texte, il doit remonter aux tous premiers temps du pyproject.toml.

Aujourd'hui, la même chose donne

setup.py ⇒ 922k résultats (https://github.com/search?q=path%3Asetup.py&type=code)

setup.cfg ⇒ 124k résultats (https://github.com/search?q=path%3Asetup.cfg&type=code)

pyproject.toml ⇒ 237k résultats (https://github.com/search?q=path%3Apyproject.toml&type=code)

Donc pyproject.toml a très clairement gagné sur setup.cfg. Et je n'ai pas de chiffres là-dessus, mais je pense qu'une partie importante des setup.py restants (qui sont quand même descendus de 1259k à 922k) concernent des projets abandonnés ou "quick hacks" qui ne seront plus jamais touchés.

Un autre facteur objectif qui montre le succès de pyproject.toml, c'est que la plupart des autoformatters, linters & co. lisent désormais pyproject.toml. Par exemple, Black, qui est ultra-populaire, ne se configure que dans un pyproject.toml. Même chose pour Ruff ou pylint.

poetry, ce ne serait pas trivial vu qu'il ne supporte pas les build backends arbitraires, et que son paquet contient une extension C, qu'il faudrait porter depuis setuptools. pdm, peut-être. Mais en fait, la question du frontend, poetry ou pdm ou pip ou build ou ce qu'on veut, n'est pas vraiment le problème ici : son extension C a des options de compilation, et de fait, aucun frontend n'interagit formidablement avec setuptools pour transmettre les options de compilation.

En tous cas, dans la section "How Does setuptools Handle --config-settings?" et sur ce commentaire GitHub, on voit qu'il a dû se plonger dans le code source de setuptools pour comprendre comment la traduction était faite parce qu'elle est mal documentée, et franchement, je pense qu'il a raison de s'en plaindre.

J'aurais été en partie d'accord avec toi si ça n'avait été qu'un projet en pur Python sans complexité de compilation. Mais là, il y a quand même de vrais problèmes tout à fait sérieux.

Merci pour le retour. Je viens de mettre le brouillon ici : https://linuxfr.org/redaction/news/l-installation-et-la-distribution-de-paquets-python

Il manque encore quelques bouts, et il reste aussi beaucoup de phrases tournées de manière trop alambiquée.

Euh… je suis un peu interloqué.

Vous avez vu qui est l'auteur du pre-print en question ?

Vous avez bien conscience que c'est le n plus grand mathématicien vivant, où n ≤ 5 ??

Autant on peut avoir des questionnements légitimes sur la qualité des publications en général, autant je ne crois pas qu'on puisse soupçonner Terence Tao d'avoir besoin de réputation et d'être donc dans la hâte pour maximiser son nombre de publications.

(genre un 'foobar bleuté' est l'unique foobar à être vert)

Tiens donc, je me demande vraiment d'où tu tires cette expression « foobar bleuté »…

Une deuxième vidéo d'un autre développeur du projet l'explique :

https://m.youtube.com/watch?v=ON0A1dsQOV0&pp=ygUUU3Vic3VyZmFjZSBndGsgdG8gcXQ%3D

Il critique le manque de documentation de GTK et le fait que selon lui, les développeurs, lorsqu'on leur pose une question, réagissent en disant que ce n'est de toute façon pas comme cela qu'il faut faire. D'après lui, GTK paraît entièrement tourné vers GNOME et peu adapté aux autres applications qui voudraient l'utiliser à leur sauce (notamment sous macOS et Windows où les widgets n'ont pas une apparence native).

s/AsciiDoc/Sphinx :-)

</troll gentil>

C'est super d'entendre parler de LilyPond sur ce site !

(Pour info, je suis développeur actif de LilyPond.)

Par curiosité : j'imagine que vous avez dû essayer aussi la fonction d'entrée MIDI proposée par Frescobaldi, en quoi était-elle insuffisante ? Qu'est-ce qui vous a poussé à créer cet outil perso ?

J'avoue être un peu sceptique sur le « Ça marche du premier coup », du moins si son intérêt est vu en terme de temps de débogage gagné. Car il n'y a pas de secret, pour que le programme marche du premier coup, Rust utilise des règles très strictes à la compilation, qui font que les cas oubliés potentiels ne sont pas possibles, et respecter ces règles demande un effort au moment du dialogue avec le compilateur qui consiste à lui faire comprendre que le code est valide. De ce point de vue, par rapport à un langage interprété laxiste du type de Python, on transfère simplement le temps de test et débogage initial des erreurs triviales vers du temps de développement où on « débogue » les erreurs de compilation (variables non définies ou pas encore initialisées, pas du bon type, etc.) Si on veut trouver les avantages potentiels d'un langage compilé au typage fort par rapport à un langage interprété laxiste au typage faible du type de Python, ils ne sont pas tant dans la facilité ou rapidité du développement en lui-même que dans le fait que des restrictions fortes peuvent faciliter la conservation d'un code maintenable lorsqu'il est écrit à plusieurs, et éviter les bugs triviaux qui ne se manifestent pas parce qu'on a oublié un cas dans les tests. À chacun de juger si les restrictions en question en valent la peine.

S'il suffisait d'un typage fort et riche pour avoir un langage qui fait soudainement rêver le monde entier, on le saurait déjà, puisque c'est le cas de la famille des langages ML, avec des fonctionnalités similaires (les enums Rust sont appelées ailleurs types algébriques, les traits ressemblent aux classes de type de Haskell ou autre, etc.).

Pour moi, le vrai intérêt de Rust est dans le fait que le langage combine des caractéristiques de langage agréable (par exemple une excellente portabilité, et une simplicité de distribution et réutilisation des modules qui me fait baver en tant que personne qui vient de passer plusieurs jours à se battre contre des build systems C++) avec des caractéristiques de langage sûr (soundness) et de langage de bas niveau adapté aux applications où la performance compte. Ce qui le rend unique, ce n'est pas tant chacune de ces caractéristiques prise isolément que leur réunion dans un même langage.