Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :
gcc
g++
rustc (pour le paquet cryptography, donc tout ce qui touche de prêt ou de loin à SSL ou la génération de nombre aléatoire)
myriade de libprout-dev
Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).
Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).
Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.
Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.
Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans (削除) C:\Program Files (削除ここまで)/opt. C'est juste plus simple.
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
Oof, tu piques la où ça fait mal ! C'est pas très fair play :p
Pour PyPI, tu as les wheels qui sont des paquets précompilés. Tu en as pour la glibc et pour Windows.
Attention par contre : https://pythonspeed.com/articles/alpine-docker-python/
Et ouais, sur Alpine, pas de glibc, musl, pas de wheels donc, du coup tu dois tout build toi même. En 2021, build un paquet Python sur Alpine peut nécessiter :
Malgré ça, même avec les wheels, on est pas au point côté Python (je pense à l'intégration de GTK en Python qui aujourd'hui ne peux pas être faite avec un simple pip install, contrairement à PySide pour Qt).
Après, on a conda qui résoud pas mal de problème, mais on est sur quelque chose de similaire à Flatpak du coup (un système complètement parallèle à celui de la distro).
Pour des écosystèmes comme Rust, ou Go, la question ne se pose pas vraiment, puisque l'artefact final est un binaire statique.
Concernant NPM, à ma connaissance, il n'existe pas d'équivalent des wheels de Python, et c'est un problème car cela complexifie grandement l'installation de paquet. Je prend comme exemple une vielle version de sass-loader dont le build system dépendait de node-gyp (je te hais) qui avait besoin de python2 mais n'utilisait pas l'alias /usr/bin/python, et donc sur les systèmes ou tu as /usr/bin/python pour python2 et /usr/bin/python3 pour python3 (coucou Debian), tu devais faire le link toi même.
Erlang/Elixir te produisent une release sous forme de tar.gz contenant le runtime complet de l'appli, que tu peux extraire ou tu veux. J'aime cette méthode.
Beaucoup de projets finissent par simplement fournir une image Docker ou un tar.gz à extraire dans
(削除) C:\Program Files (削除ここまで)/opt. C'est juste plus simple.https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg