Environnement moderne de travail Python

Posté par sispheor le 28 mai 2022 à 19:27. Édité par palm123, Pierre Jarillon, Ysabeau 🧶, Nils Ratusznik et ted. Modéré par Ysabeau 🧶. Licence CC By‑SA.

Étiquettes :

mai

2022

Environnement moderne de travail Python

Si vous développez ou utilisez des programmes s’exécutant au-dessus de l’interpréteur Python, il peut arriver que vous vous retrouviez avec un environnement très dégradé sur votre poste de travail..

Je propose ici de découvrir un ensemble d’outils permettant de configurer des environnements Python qui vous éviteront de polluer votre système ou vos futurs environnements de développement. En effet, entre votre système Linux et les multiples projets de développement sur lequel vous travaillez vous avez souvent besoin d’interpréteur Python dans des versions différentes ou de librairies dans des versions particulières.

Dans ce guide, nous allons voir comment installer un environnement Python répondant aux cas d’usage suivants :

gestion facile de multiple versions de l’interpréteur Python ;
isolation d’applications CLI basées sur Python ;
création d’environnements de développement isolés les uns des autres.

Sommaire

Installation de l’environnement
- Pyenv
- Pip
- Pipx
- Poetry
Mot de la fin

Installation de l’environnement

Nous allons utiliser les outils suivants:

pyenv ;
pip ;
pipx ;
poetry.

Pyenv

Pyenv est un outil qui permet d’installer et gérer facilement vos interpréteurs Python. Il vous permet d’utiliser un interpréteur qui n’est pas celui de votre système.

Les distributions Linux sont souvent livrées avec un Python pré-installé (généralement sous /bin/python) permettant de gérer des programmes nécessaires au bon fonctionnement de votre système. Certains de ces programmes sont critiques et il est donc recommandé de ne pas toucher à l’interpréteur natif de votre système Linux.

Installation de Pyenv

curl https://pyenv.run | bash

Une fois installé, il faut modifier la configuration de votre shell afin qu’il initialise Pyenv à chaque ouverture de terminal.

Ajoutez ces lignes a votre bashrc (ou zshrc):

export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

Ouvrez un nouveau terminal et testez que pyenv :

pyenv
pyenv 2.3.0

Pour installer une version particulière de Python, utilisez la commande pyenv install. Par exemple :

pyenv install 3.9.10

Vous pouvez lister les versions de Python installées

pyenv versions

Pip

Pip est tout simplement un installeur de librairie Python disponible sur https://pypi.org/.

On télécharge l’installeur officiel :

wget https://bootstrap.pypa.io/get-pip.py

On le lance (avec le python3 du système)

sudo python3 get-pip.py

On vérifie que pip3 est bien installé pour notre interpréteur système

pip3 --version
pip 22.1 from /usr/local/lib/python3.10/dist-packages/pip (python 3.10)

Pipx

Pipx permet d’installer des outils CLI dans des environnements isolés et les expose de la même façon que s’ils avaient été installés par pip ou un paquet système.

Très pratique pour éviter les conflits entre plusieurs outils de CLI qui reposent souvent sur des librairies open-source communes mais dans des versions différentes. Il permet aussi d’installer plusieurs versions différentes d’une application CLI.

Installation du paquet venv qui permet de créer des environnements virtuels. Cette librairie est utilisée par pipx pour isoler les installations.

sudo apt install python3-venv

Installation de pipx via pip

sudo pip3 install pipx virtualenv

Pipx expose les applications qu’il installe en ajoutant un lien dans le chemin ~/.local/bin. Il faut donc ajouter ce chemin à votre « PATH ». Dans votre bashrc (ou zshrcè) :

export PATH="$PATH:$HOME/.local/bin/"

On va à présent installer une application basée sur Python. Prenons par exemple Ansible. Ici, nous précisons à pipx d’utiliser l’interpréteur Python installé avec Pyenv précédemment :

pipx install --python /home/nico/.pyenv/versions/3.9.10/bin/python3.9 ansible --include-deps

Ansible est à présent installé dans un environnement virtuel. Les bibliothèques qu’il utilise sont isolées des bibliothèques Python utilisées par le système.

Pour lister les programmes que vous avez installés via pipx :

pipx list

Si le programme que vous avez installé a lui-même besoin d’autres bibliothèques Python pour fonctionner, c’est le cas, par exemple, avec Ansible dont les modules reposent parfois sur des bibliothèques communautaires, vous pouvez les injecter dans l’environnement virtuel. Dans cet exemple, on injecte les bibliothèques pyvmomi, python-ldap, kubernetes et hvac à notre environnement ansible :

pipx inject ansible pyvmomi python-ldap kubernetes hvac

Il est possible également de gérer plusieurs versions d’un même programme et de l’exposer au système avec un suffixe différent. Ainsi, je souhaite installer la dernière version d’Ansible (Ansible 5) tout en gardant la première version installée :

pipx install --suffix -5 --python /home/nico/.pyenv/versions/3.9.10/bin/python3.9 --include-deps ansible

La commande ansible-playbook pour cette version est alors exposée sous ansible-playbook-5.

ansible-playbook-5 --version
ansible-playbook [core 2.12.5]
  config file = None
  configured module search path = ['/home/nico/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/nico/.local/pipx/venvs/ansible/lib/python3.9/site-packages/ansible
  ansible collection location = /home/nico/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/nico/.local/bin//ansible-playbook
  python version = 3.9.10 (main, May 19 2022, 14:16:15) [GCC 11.2.0]
  jinja version = 3.1.2
  libyaml = True

Poetry

Poetry est un gestionnaire de dépendances Python. C’est une sorte de pip++. Il permet d’installer des librairies Python, de s’assurer que l’environnement de développement d’un projet soit isolé et identique pour tous les développeurs, de gérer les conflits d’installation ou encore de publier son paquet Python.

Poetry est un outil CLI écrit en Python, pour l’installation nous pouvons donc utiliser pipx :

pipx install poetry

On vérifie l’installation

poetry --version
Poetry version 1.1.13

Création d’un projet

poetry new poetry-demo

Cette commande effectue 2 choses :

la création d’un répertoire pour le projet avec des fichiers nécessaires à la gestion des dépendances,
la création d’un environnement virtuel pour le projet.

tree poetry-demo

poetry-demo
├── pyproject.toml
├── README.rst
├── poetry_demo
│   └── __init__.py
└── tests
    ├── __init__.py
    └── test_poetry_demo.py

Si l’on veut ajouter une librairie, on va alors se servir de la CLI :

poetry add django

Si l’on souhaite activer l’environnement virtuel du projet, on se place dedans et on appelle la commande shell.

cd poetry-demo
poetry shell

Mot de la fin

Ce tutoriel a été réalisé sur une machine Ubuntu 22.04, mais devrait fonctionner de la même façon sur d’autres distributions. Il existe, bien sur, d’autres façons de gérer ces environnements Python, ceci n’est qu’un exemple qui permet de travailler plus proprement avec Python. Il fonctionne dans un contexte d’administration système avec la gestion des CLI via pipx ou dans un contexte de développement logiciel via l’usage de poetry.

# XDG

Posté par Glandos le 28 mai 2022 à 22:36. Évalué à 10.

export PYENV_ROOT="$HOME/.pyenv"

😞

Ça aurait été tellement bien dans ~/.local/share/ avec des binaires dans ~/.local/bin. Alors oui, ça semble possible de le faire, mais par défaut, ça crée un énième répertoire, dommage.

Après, moi, je râle gratuitement contre tout ce qui me demande curl | bash
- [^] # Re: XDG
  
  Posté par sispheor le 28 mai 2022 à 22:43. Évalué à -2.
  
  C'est quoi le problème avec curl Bash ?
  - [^] # Re: XDG
    
    Posté par Dafyd le 28 mai 2022 à 23:20. Évalué à 10. Dernière modification le 28 mai 2022 à 23:20.
    
    Tu exécutes sur ta machine du code provenant d'internet sans vérifier au préalable ce qu'il fait. Il suffirait que le site d'où tu curl se soit fait pirater, et tu injectes un mineur de bitcoin sur ta machine !
    
    Le pire restera curl | sudo bash.
    - [^] # Re: XDG
      
      Posté par Epy le 29 mai 2022 à 00:55. Évalué à 9.
      
      En plus, ce curl <domaine> | bashlà lance un autre script qui à son tour fait curl <dépot github> | bash
      
      Donc si le domaine est perdu ou abandonné, il est possible d'y mettre n'importe quoi et de le faire installer par toutes celles et ceux qui ne vérifieront pas. :/
      - [^] # Re: XDG
        
        Posté par Storm le 30 mai 2022 à 18:00. Évalué à 7.
        
        Je crois me souvenir avoir vu passer des PoC d'exploits qui permettaient de détecter si on pipait dans bash ou dans un fichier. Ça permet donc de distribuer un contenu différent entre un curl | bash et un curl > mon-script.sh. Bien entendu je n'arrive plus à retrouver..
        
        Aussi si jamais la connexion est interrompue pendant le transfert, ben on se retrouve possiblement avec son système dans un état instable.
        
        Bref, si vous voulez utiliser curl | bash, passez au moins par un fichier pour être protégé en cas d'erreur réseau!
        
        [^] # Re: XDG
        
        Posté par pampryl le 03 juin 2022 à 13:51. Évalué à 2.
        
        Je ne vois pas trop comment, au travers de l'appel HTTP, effectué par curl, tu peux savoir si la sortie sera une redirection de stdin dans un fichier, un pipe ou si tu vas directement utiliser l'option --output. Coté HTTP, cette information n’apparaît pas et tu ne peux pas servir un contenu différent si la requête HTTP ne varie pas.
        
        Par contre tu peux détecter que c'est curl via le user-agent et servir un autre contenu pour celui·celle qui voudrait lire le contenu depuis son browser par exemple.
        
        [^] # Re: XDG
        
        Posté par barmic 🦦 le 03 juin 2022 à 14:20. Évalué à 3.
        
        Il suffit que le début du code que tu envoie exécute quelque chose que tu peux détecter.
        Si tu rappel ton serveur avec un identifiant unique par exemple.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: XDG
        
        Posté par seveso le 05 juin 2022 à 00:12. Évalué à 5.
        
        Je ne vois pas trop comment, au travers de l'appel HTTP, effectué par curl, tu peux savoir si la sortie sera une redirection de stdin dans un fichier
        
        Voici un lien qui répondra a ta question.
    - [^] # Re: XDG
      
      Posté par sispheor le 29 mai 2022 à 07:42. Évalué à -10.
      
      Je ne suis pas d'accord avec ça. Vous pensez que du code malicieux ne peut être présent que d'en du Bash?
      Bien sûr que non.
      Avez vous lu entièrement le code de votre navigateur ? Le code de votre kernel linux? Le code de votre OS?
      Non.
      Et pourquoi ?
      Pas parce que c'est du Bash. Mais parce que vous faites confiance à la source.
      Si vous faites confiance en la source alors vous n'avez pas à lire tout le code.
      Du code malicieux peut être distribué par pleins de moyens. Ce n'est pas parce que vous utilisez un package manager que vous êtes en sécurité. Encore récemment des liens npm ont été infectées. Et python encore plus récemment avec le problème des clés Amazon.
      Bref, ce n'est pas la sécurité que de ne pas faire du curl Bash. Sinon les grands mastodontes sur le web pour des gros projets le feraient justement plus.
      - [^] # Re: XDG
        
        Posté par Dafyd le 29 mai 2022 à 07:52. Évalué à 10.
        
        Bonjour,
        
        Évidemment non, je ne vérifie pas le code de tout mon OS, cependant, il est installé via des RPM (ou DEB, etc…) signés par l'émetteur. Cette signature est vérifiée par le gestionnaire de paquets avant installation, et donc seuls les paquets officiellement produits par l'éditeur peuvent s'installer. Si cet éditeur se fait pirater au point de se faire voler sa clé privée, il lui suffit de révoquer son certificat publiquement, et le gestionnaire de paquets ne fera plus confiance aux paquets signés par lui.
        
        Ce n'est pas parfait, mais c'est tout de même mieux qu'un code hébergé sur un dépôt github dont on ignore la maîtrise.
        
        [^] # Re: XDG
        
        Posté par octane le 29 mai 2022 à 22:28. Évalué à 6.
        
        je vais me faire l'avocat du diable, mais il parle de pyenv. Du coup tu dis:
        
        c'est tout de même mieux qu'un code hébergé sur un dépôt github dont on ignore la maîtrise.
        
        Or, pyenv est hébergé sur github. Donc faire curl github.com/pyenv | bash c'est mal. Mais faire git clone github.com/pyenv && pyenv/bin/pyenv c'est plus sécurisé?
        
        Malheureusement si tu veux tester un logiciel, tu vas tôt ou tard lancer un binaire précompilé, ou un script que tu n'auras pas relu.
        
        Maintenant, ouais, je hurle contre le curl | bash pour plein d'autres raisons. Mais là, ce qui m'ennuie c'est que ça devient du cargo cult, tout le monde dit que c'est mal, tout le monde hurle en expliquant que c'est mal mais plus personne ne donne vraiment de raisons. Petite histoire : j'ai connu des devs qui refusaient absolument d'utiliser strcpy (c'est bien) mais sans avoir compris les raisons. Du coup, on voyait des contorsions assez tordues dans des cas idiots, genre strncpy(dst, src, strlen(src)); [CRANE D'OCTANE QUI SE FRACASSE CONTRE LE CLAVIER QUAND IL LIT CA EN CODE REVIEW].
        
        Enfin voilà, tout ça pour dire que curl | bash faut pas utiliser, mais faut pas se bercer d'illusions non plus sur les paquets de la distro magiquement vérifiés.
        
        Si cet éditeur se fait pirater au point de se faire voler sa clé privée, il lui suffit de révoquer son certificat publiquement, et le gestionnaire de paquets ne fera plus confiance aux paquets signés par lui.
        
        Parceque se pose la question du code review de l'éditeur. Et si le maintener[1] fait un git clone && debuild etc… alors le risque d'apt-get install pyenv est il plus faible qu'un curl | bash ? En vrai? Et comment as tu vérifié que le maintener a bien géré l'install? C'est pas en faisant confiance à son certificat….
        
        [1] no shame pour le maintener je sais que c'est un boulot difficile
        
        [^] # Re: XDG
        
        Posté par Dafyd le 29 mai 2022 à 23:10. Évalué à 2. Dernière modification le 29 mai 2022 à 23:13.
        
        Sur le fond, je suis d'accord. A la fin, tu es obligé de faire confiance à l'éditeur du code, a moins de faire un audit complet. Donc que tu le pipe depuis curl ou que tu l'exécutes, le résultat est normalement le même (sauf si ta connection saute pendant le curl, ça interrompt le script).
        
        C'est plus sur le principe, on voit le curl | sh, voir sudo sh, se banaliser, et ça peut être utilisé a des fins malveillantes car un néophyte ne s'en méfiera pas du tout. Il vaut mieux éviter et surtout éviter de montrer ce mauvais exemple aux nouveaux.
        
        [^] # Re: XDG
        
        Posté par Psychofox (Mastodon) le 30 mai 2022 à 09:32. Évalué à 3.
        
        C'est plus sur le principe, on voit le pip install, voire poetry add se banaliser, et ça peut être utilisé a des fins malveillantes car un néophyte ne s'en méfiera pas du tout. Il vaut mieux éviter et surtout éviter de montrer ce mauvais exemple aux nouveaux.
        
        Corrigé pour toi ;-)
        
        J'attends le ah oui mais c'est pas pareil.
        
        [^] # Re: XDG
        
        Posté par barmic 🦦 le 30 mai 2022 à 12:45. Évalué à 2.
        
        Si cet éditeur se fait pirater au point de se faire voler sa clé privée, il lui suffit de révoquer son certificat publiquement, et le gestionnaire de paquets ne fera plus confiance aux paquets signés par lui.
        
        C'est à vérifier pour chaque gestionnaire. Vérifier les révocations ça peut prendre du temps et ne pas être fait systématiquement (comme avec tls par exemple).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: XDG
        
        Posté par sispheor le 01 juin 2022 à 11:46. Évalué à -1.
        
        L'argument du signing est meilleur que celui du problème de l'execution de code que vous avez mentionné en premier lieu.
        
        Mais meme un paquet signé par un éditeur peut contenir a son insu des problèmes dans des librairies qu'il utilise pour son propre fonctionnement.
      - [^] # Re: XDG
        
        Posté par Glandos le 29 mai 2022 à 22:36. Évalué à 10.
        
        D'autres ont déjà répondu mais oui, le problème, c'est la chaîne d'intégrité.
        
        Aujourd'hui, si on se retrouve face à des bibliothèques malicieuses sur NPM, c'est parce qu'elles ne sont pas signées. yarn.lock et package-lock.json font heureusement de la vérification d'intégrité, mais sur une version donnée. Attention, ce problème existe également avec du typosquatting sur PyPI et RubyGems.
        
        Le gestionnaire de paquets de ma distribution utilise des signatures pour ce genre de choses. S'ils se font pirater, oui, c'est perdu pour moi, à tous les niveaux. Mais il est plus facile de « voler » un nom de domaine (voire simplement de le perdre) que de pénétrer la sécurité de Debian/Ubuntu/RedHat et n'importe quelle grosse distribution.
# Conda

Posté par bayo le 29 mai 2022 à 11:53. Évalué à 9.

Je suis étonné de ne pas lire un mot sur conda. Du coup, au cas ou ça intéresse, j'en glisse 3.

Il a initialement été créé pour pouvoir installer et travailler avec les bibliothèques Python demandant une compilation binaire, genre numpy, scipy, typiquement pour du traitement de données scientifique. Aujourd'hui avec les wheel c'est de l'histoire ancienne. Mais a l'époque il n’était pas possible de distribuer simplement ce genre de bibliothèques ; et compiler sois-même des partie de lib Python écrite en Fortan sous Windows était un calvaire.

Aujourd'hui, la principale différence avec les autres environnements c'est de ne pas se limiter aux bibliothèques Python, il peut déployer les bibliothèques purement binaire, y compris les compilateurs C. Par exemple pysqlite3 va dépendre du paquet sqlite qui va installer la lib de référence, avec son exécutable de référence, avec même peut être les header C de référence.

On peut s'en servir pour faire du développement Python, R, Ruby, Lua, Scala, Java, JavaScript, C/C++, Fortran (liste non contractuelle copié-collé du site officiel). Chez mon employeur on s'en sert aussi en prod pour gommer l'hétérogénéité de notre parc de machines.

Il fournit plusieurs dépôts de référence (channel), notamment conda-forge maintenu par la communauté, mais on en trouve aussi des privé. Je viens de regarder, il a une veille version non maintenue de inkscape, mais c'est juste pour dire qu'on peut y packager tout et n'importe quoi.

Voila. J’espère que c'est pas trop hors sujet.
- [^] # Re: Conda
  
  Posté par Spyhawk le 29 mai 2022 à 13:07. Évalué à 4.
  
  C'est complètement dans le sujet, et j'étais moi même surpris de ne voir aucune référence à Conda dans l'article. Merci pour ton ajout donc!
  
  It was originally developed to solve difficult package management challenges faced by Python data scientists
  
  A l'origine, Anaconda est une distribution de centaines de paquets python certifiés pour fonctionner bien entre eux, à la manière d'une distribution Linux. Conda est le package manager, et il existe une distribution minimalist (miniconda) qui fournit juste ce qu'il faut pour ajouter ce dont on a actuellement besoin, avec le choix de paquets qui proviennent d'un dépôt "stable" ou en rolling release (conda-forge).
  
  C'est la méthode que je préfère pour gérer mes environnements python (intégration avec VS code ou PyCharm), et il fonctionne parfaitement avec pip dans les cas ou les paquets ne sont pas disponible directement via Conda.
  - [^] # Re: Conda
    
    Posté par François (site web personnel) le 29 mai 2022 à 21:10. Évalué à 3.
    
    Sans avoir d'exemple précis à donner, j'ai toujours fini par avoir des problèmes avec conda, et mes étudiants encore récemment. Poetry a tout changé…
    - [^] # Re: Conda
      
      Posté par bayo le 04 juin 2022 à 15:09. Évalué à 2. Dernière modification le 04 juin 2022 à 15:10.
      
      Je ne connais pas poetry, je pensais que ça remplaçait uniquement les libs pour le packaging, genre setuptools/distutils.
      
      Une différence de conda, c'est qu'il a ses propre paquet et repo. Du coup je pense qu'on se retrouve assez souvent avec une recette conda qui n'est pas aligné avec le projet source (genre les dépendances), ou qui sera un peu en retard de pypi. Si on travail au fil de l'eau, en plus des problèmes des projets, on peut aussi hériter des problèmes du packaging.
      
      Mais oui, conda, on apprend a s'en servir en s'y cassant les dents :-D
# pew

Posté par yabb85 le 29 mai 2022 à 20:47. Évalué à 4.

J'utilise pew pour gérer mes virtualenv et cet outil m'a grandement simplifiée la vie. Tous les venv sont au même endroit. On peut les lister avec la commande pew ls et en choisir un avec pew workon et plein d'autres choses.
# pipx et gui

Posté par François (site web personnel) le 29 mai 2022 à 21:12. Évalué à 2.

pipx permet aussi l’installation de programme graphique. Par contre il faut que les toolkit (qt ou gtk typiquement) soient installés côté système. J’installe comme ça Spyder ou Napari par exemple.
# sudo pip

Posté par JulienPalard le 29 mai 2022 à 21:22. Évalué à 6.

Je suis étonné de voir des sudo pip : je ne l'utilise jamais et le déconseille toujours : pour moi ça ressemble à un aimant à problèmes, ai-je raté quelque chose ?

Chez moi tout ce qui est hors de mon home c'est apt qui s'en occupe (seul, et donc sans problèmes), et pip se cantonne à des venv ou à ~/.local/ : pas de problèmes.
- [^] # Re: sudo pip
  
  Posté par sispheor le 29 mai 2022 à 22:36. Évalué à 1.
  
  C'est parce que la le pip3 utilisé est celui du système. Les paquets vont être installés dans sites-packages qui n'est accessible qu'en root.
  Mais après il est possible de faire un venv pour mettre ces libs dedans sans sudo effectivement.
  La comme c'est des outils de base qui ne vont pas beaucoup bouger je me permets ce raccourci.
  - [^] # Re: sudo pip
    
    Posté par Goffi (site web personnel, Mastodon) le 30 mai 2022 à 10:11. Évalué à 5.
    
    salut,
    
    tu peux utiliser --user avec le pip système, ça installera dans ton ~/.local.
# pip + venv + prompt

Posté par François GUÉRIN (Mastodon) le 30 mai 2022 à 09:56. Évalué à 2.
Bonjour,

Je développe des applications en python au quotidien, et voici comment je procède
- Pour les outils "de base" pour le développement (black[d], isort, flake8, pytest)
  shell $ pipx install <application>
- Pour les environnements par projets
  shell $ cd Projects/<mon_projet>/ $ python3 -m venv --prompt <mon_projet> ./venv $ . venv/bin/activate (mon_projet)$
  (Une évolution récente de liquidprompt permet d'afficher le prompt du venv.
  https://github.com/nojhan/liquidprompt/issues/708
# Environnement très dégradé

Posté par Guillawme (site web personnel, Mastodon) le 30 mai 2022 à 12:00. Évalué à 8.

Si vous développez ou utilisez des programmes s’exécutant au-dessus de l’interpréteur Python, il peut arriver que vous vous retrouviez avec un environnement très dégradé sur votre poste de travail..

Obligatory xkcd: https://xkcd.com/1987/
- [^] # Re: Environnement très dégradé
  
  Posté par David Delassus (site web personnel) le 30 mai 2022 à 20:56. Évalué à 4.
  En tant que développeur de librairie, j'utilise poetry, il va s'occuper de générer le setup.py comme un grand et de pousser sur PyPI. Mes utilisateurs font comme ils veulent ensuite.
  
  En tant que développeur d'application --> https://pyinstaller.org/en/stable/
  
  Tout embarqué dans un seul exécutable (certes un peu plus gros vu qu'il embarque l'interpréteur Python et tout les modules importés). Ensuite je fournis le ".exe" via les releases Github ou, si la motivation est là, le paquet deb/rpm/msi/…
  
  En tant qu'utilisateur, je laisse la distribution gérer son truc elle même, j'ai même pas envie de savoir quelle version de Python elle utilise. De toute façon, mon Python à moi il est dans /opt car je suis les beta/rc/etc… qui sont rarement dans les dépôts.
  
  Au final, cela fait bien 15 ans que je n'ai pas subi ce que décrit ce xkcd.
  
  D'ailleurs :
  - easy_install n'existe plus (aucun de mes venv ne possède la commande)
  - conda semble être une niche, car je ne l'ai vu que chez des data engineer/data scientist, les wheels ont aidé à cette situation
  - il existe désormais pyproject.toml qui (peut être dans 10 ans ?) devrait standardiser le fonctionnement des gestionnaires de paquets de Python
  Le graph devrait se simplifier un peu désormais.
  
  Je me fais un peu l'avocat du diable, mais les reproches fait au système de paquet de Python me semblent légèrement obsolètes.
  
  https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
  - [^] # Re: Environnement très dégradé
    
    Posté par bayo le 04 juin 2022 à 15:18. Évalué à 1. Dernière modification le 04 juin 2022 à 15:18.
    
    Oui, ça c'est beaucoup stabilisé. Ça partait de loin. Du coup c'est le bon moment de changer de langage.
- [^] # Re: Environnement très dégradé
  
  Posté par Gil Cot ✔ (site web personnel, Mastodon) le 31 mai 2022 à 03:46. Évalué à 4.
  
  En effet, et certaines personnes hurlent « stop »
  https://linuxfr.org/users/gilcot/liens/python-please-stop-screwing-over-linux-distros#comment-1873410
  
  En plus faut s'y retrouver quoi
  https://linuxfr.org/users/bersace/journaux/python-3-n-existe-pas
  
  “It is seldom that liberty of any kind is lost all at once.” ― David Hume
# pdm

Posté par oau le 30 mai 2022 à 20:54. Évalué à 1.

je suis récemment passé de pypenv à pdm et j'en suis content. Conda c'est une bête d'usine à gaz. Pdm c'est bien :)
# quid novis?

Posté par Gil Cot ✔ (site web personnel, Mastodon) le 31 mai 2022 à 03:31. Évalué à 3.
J'ai l'impression d'une tentative de refaire certaines dépêches sans les référencer de surcroit
Le côté positif c'est que ça remet le sujet en lumière et ouvre les commentaires.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume
- [^] # Re: quid novis?
  
  Posté par Pol' uX (site web personnel) le 31 mai 2022 à 11:23. Évalué à 5.
  
  A l'image de l'illisibilité de l'environnement de paquetage python ? :)
  
  Adhérer à l'April, ça vous tente ?
# Prenons le problème à l'envers...

Posté par lym le 03 juin 2022 à 12:54. Évalué à 1. Dernière modification le 03 juin 2022 à 12:54.

Pour ne pas niquer sa distro sans tomber dans les travers bien connus du genre depuis Java (chaque applicatif traînant sa JVM pour ne pas avoir d'incompatibilités), être homogène à ce niveau et n'utiliser que ce qui est dans les dépôts en 1ère sélection tout en bannissant ce qui est manifestement codé en mode agile (mon crédo: "Les post-it s'envolent, les spec restent") en seconde lame du rasoir.

Si on veut être vraiment portable, se limiter à des implémentations minimalistes de python pour l'embarqué.

Certes, cela peut limiter les usages de python à un bash++, mais n'est-ce pas l'avoir fait sortir de ce cadre qui cause les problèmes?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.