jeanas a écrit 161 commentaires

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.