jeanas a écrit 129 commentaires

Le problème est assez simple, c'est que Conda et pip ne se parlent pas entre eux.

Si tu installes le paquet foo avec pip dans un environnement Conda, et que tu fais ensuite conda upgrade bar, Conda risque d'installer une version de bar incompatible avec la version de foo, et ainsi de casser foo.

L'inverse vaut aussi. Si tu fais pip install foo et que pip se sent obligé de mettre à jour bar pour satisfaire les dépendances de foo, cela risque de casser le paquet baz de Conda qui dépendait de bar.

Pipenv, c'est une longue histoire. Pour la faire courte, Kenneth Reitz, dans une recherche malsaine de popularité, l'a vendu comme un outil miracle et plus officiel qu'il ne l'était vraiment, alors que Pipenv était encore trop limité, en particulier au niveau de la rapidité. Cela a causé un véritable fiasco, qui est l'une des raisons pour lesquelles toute proposition du type « rendons l'outil X officiel » rencontre beaucoup de résistance aujourd'hui.

À un moment, il n'a plus été maintenu pendant un bon moment. Il a trouvé de nouveaux mainteneurs depuis, donc je ne sais pas trop quoi en penser maintenant.

Quant aux recommandations sur packaging.python.org, elles ne sont malheureusement pas à jour. Cf. https://github.com/pypa/packaging.python.org/issues/1468, issue que j'ai justement ouverte hier.

Désolé, je ne comprends pas la pertinence de Guix dans ce contexte. Guix est un gestionnaire de paquets générique, tourné vers aucun langage en particulier. Il ne sait pas lire ou installer les formats de paquets Python, il ne sait pas créer ou gérer des environnements virtuels, installer un paquet en mode éditable, résoudre les dépendances depuis PyPI, ou que sais-je. Je ne vois pas quel problème il peut résoudre dans ce contexte.

(En plus, Guix ne fonctionne que sous Linux.)

Merci pour les remerciements, ça fait plaisir !

J'utilise Hatch sur Pygments, dont je suis mainteneur (sauf qu'il y a du tox aussi, c'est pour ça que je disais que j'hésite à tanner mes co-mainteneurs pour passer à Hatch alors que je les ai déjà tannés pour qu'on sorte de Make). Et aussi sur d'autres projets qui n'ont pourtant pas de déclaration d'environnements Hatch, par exemple sur Sphinx, en me rajoutant mon fichier hatch.toml perso. Et pour tous mes scripts persos aussi.

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é »…