Python — partie 3 — Installation de Python et de paquets

Posté par  (site web personnel) . Édité par lolop, ZeroHeure, Ysabeau 🧶, Anonyme, Davy Defaud, esdeem, Adrien Dorsaz, palm123, Benoît Sibaud, M5oul, Cetera, Dimitri Merejkowsky, barmic 🦦, tisaac, Bruno Michel et Florent Zara. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
23
22
sept.
2019
Python

Pour cette rentrée 2019, faisons le point sur Python : actualité, bonnes pratiques, astuces, projets intéressants, témoignages…

Cette troisième dépêche présente différentes façons d’installer Python, ainsi que l’installation de paquets supplémentaires : applications et bibliothèques Python. 🖥 💻 🐍

Python installation

Sommaire

Licence

Cette dépêche est publiée sous licence CC0 (sous domaine public dans les pays où cela est possible) pour te permettre de recopier, modifier, réutiliser et republier ce contenu sans t’obliger à citer ses auteurs (sauf que la loi de certains pays comme la France t’oblige quand même à citer les auteurs).

Remerciements

Un immense merci à lolop et Étienne Bersac pour leurs nombreuses contributions aux dépêches Python. 👏 👏 👏 Merci aussi à toutes les autres personnes qui ont participé à leur rédaction. 😉 Continuons à améliorer les prochaines dépêches. ✍😎

Les interpréteurs Python

L’interpréteur Python de référence, CPython, est distribué par la Python Software Foundation. Il met en œuvre les évolutions du langage pilotées par la communauté.

D’autres interpréteurs Python existent toutefois :

Les distributions Python

L’interpréteur Python et tout son écosystème de paquets qui gravite autour représente un ensemble de logiciels : une distribution.

La distribution de référence est disponible sur www.python.org. Elle fournit un ensemble déjà conséquent de bibliothèques standards (« piles inclues »), et permet d’installer beaucoup d’autres paquets Python fournis par la communauté, le plus souvent sous licence libre. Les autres distributions se basent généralement sur l’interpréteur de référence CPython, en y ajoutant leurs propres touches.

Une autre distribution très utilisée est Anaconda, surtout par les scientifiques des données (data scientist) et de l’apprentissage automatique (machine learning). La distribution Anaconda fournit les paquets standards de Python ainsi que d’autres paquets déjà compilés qui peuvent être difficiles à installer sous Windows ou macOS (besoin de compilation de code C ou Fortran).

Cette distribution est toutefois très volumineuse, car elle installe de très nombreux outils et applications. L’alternative Miniconda, est une distribution plus légère et basée sur le même outil de gestion de paquets conda. Miniconda permet de sélectionner plus finement les paquets à installer.

D’autres distributions Python existent comme ActivePython, WinPython ou encore Python(x,y). N’hésitez pas à partager dans les commentaires vos retours d’expériences et vos recommandations.

Note : Il est possible de faire cohabiter sur la même machine différentes distributions de Python. Il est aussi possible d’installer différent versions de Python. Le problème ensuite est de lancer le bon exécutable lorsqu’on tape python3. Sans précision, ça sera le premier exécutable python3 trouvé dans les répertoires du PATH. On doit spécifier /chemin/vers/python pour y choisir un exécutable particulier. Et si l’on utilise un « environnement virtuel », l’exécutable python est celui lié à cet environnement.

Installation de Python

De nombreux lectrices et lecteurs de LinuxFr.org utilisent Windows, et sont bien souvent forcés (boulot, enseignement). Nous avons donc décidé d’expliquer également l’installation de Python pour Windows. Les lectrices et lecteurs sous macOS ne sont pas non plus oubliés. Nos excuses pour celles et ceux sous *BSD, Haiku, Illumos, OpenIndiana, GNU Hurd, ReactOS, AROS, Android, iOS…

GNU/Linux

Les deux distributions les plus utilisées sont la distribution de référence, CPython, et Miniconda. Voici quelques méthodes d’installation.

Installation de CPython via les paquets fournis par sa distribution

Attention le paquet pip est fourni à part. Ci‑dessous un exemple pour Ubuntu. Je recommande l’installation des paquets python3‑dev et build‑essential qui pourraient être nécessaires quand pip (ou pipenv) installent certains paquets nécessitant une compilation de dépendances basées sur d’autres langages de programmation comme C et Fortran.

sudo apt update
sudo apt install python3 python3-pip
sudo apt install python3-dev build-essential

Installation du snap conda

Avec, par exemple, la logithèque Ubuntu (GNOME Software), ou la ligne de commande ci‑dessous :

sudo apt install snapd
sudo snap install --beta conda # version stable pas dispo

Exemple pour chercher et installer le paquet Python black :

$ conda search black
Loading channels: done
# Name Version Build Channel
black 19.3b0 py_0 pkgs/main
$ conda install black
[…]

Notons que le snap conda n’est pas indiqué comme libre.
Attention à l’espace de stockage disponible, Miniconda et Anaconda ont tendance à être très gourmands, on arrive assez rapidement à des gigaoctets occupés.

Utilisation d’environnements virtuels avec des versions de Python spécifiques

C’est l’objet de la dépêche suivante (et est aussi permis avec conda).

Il est également possible de télécharger des exécutables et de les installer à la main. Miniconda et Anaconda sont disponibles sous cette forme. Attention à vérifier que les logiciels proviennent bien d’une source de confiance et à les exécuter, si possible, dans un bac à sable (sandbox). Voir le projet Firejail.

macOS

macOS fournit de base Python 2.7 :

 $ python --version
 Python 2.7.15

Voici quatre possibilités pour installer Python 3 sur macOS :

  1. le site python.org fournit CPython pour macOS, qui nécessite une petite centaine de mégaoctets ;

  2. si HomeBrew est installé, celui‑ci permet d’installer CPython empaqueté par la communauté :

    $ brew install python3
$ python3 --version
Python 3.7.0

  3. la distribution Miniconda ;

  4. la distribution Anaconda.

Windows

Toutes les versions de CPython sont sur le site officiel. Les installateurs executable installer et web‑based installer simplifient l’installation.

Comme expliqué par Sam dans son article « Lancer correctement Python et ses commandes cousines », ne pas oublier de mettre le répertoire des exécutables Python dans la variable d’environnement %PATH%. L’installateur propose de le faire en cochant la case « [✓] Add Python 3.7 to PATH » :
Fenêtre de l’installateur de Python 3.7 avec la case à cocher pour rajouter l’exécutable Python dans la variable d’environnement PATH

Citons une manière familière pour les Ubunteros d’installer CPython : avec le Windows Subsystem for Linux (WSL). Pour cela, choisir une image GNU/Linux, par exemple l’image Ubuntu, et ouvrir un terminal avec un interpréteur de commandes de type Bash. Avec la nouvelle version WSL2, les applications graphiques GNU/Linux devraient aussi pouvoir s’exécuter sur Windows et avec des performances acceptables.

Téléchargez les alternatives Miniconda et Anaconda pour les installer.

Lire aussi la description, étape par étape, de l’installation d’Anaconda sous Windows.

Quel python adopter ?

Installer des paquets Python

Sous GNU/Linux, avec le gestionnaire de paquets

Les gestionnaires de paquets des distributions GNU/Linux fournissent un certain nombre de bibliothèques Python. Leur installation via ces outils permet de s’assurer qu’elles seront compatibles avec la version de Python installée en standard par le système, et mises à jour lorsque nécessaire. En revanche, elles ne seront peut‐être pas dans la version la plus récente disponible. L’installation de cette façon rend ces bibliothèques disponibles pour tous les utilisateurs de l’ordinateur.

Attention lors de l’installation, ces bibliothèques sont souvent empaquetées séparément pour Python 2 et pour Python 3 ; en général la version de Python est spécifiée dans le nom du paquet.

Exemple sous Debian/Ubuntu : sudo apt install python3-exif.

Sous n’importe quel système d’exploitation, avec pip

L’outil pip permet d’installer et de gérer des paquets Python directement en liaison avec le Python Package Index ; dépôt qui rend ceux‑ci accessibles à tout le monde via l’Internet.

Attention, pour les personnes qui disposent d’outils de gestion de paquets pour le système de leur ordinateur (typiquement tous les UNIX), pip vient en concurrence. Comme Python est très souvent utilisé par des outils de maintenance ou d’administration des machines, cela peut causer des problèmes : installation de versions de certains paquets directement à la place de ceux du système, ou encore installation de certains paquets pour l’utilisateur qui ont la priorité par rapport aux versions installées par le système. Il est très fortement conseillé d’utiliser des environnements virtuels, comme cela est présenté dans la dépêche suivante. Il est prohibé d’installer un paquet via pip dans le cadre d’une commande sudo (cela risque de casser votre système).

Normalement pip est installé directement (ou disponible dans les paquets de votre distribution GNU/Linux). Si ce n’est pas le cas, un script get-pip.py permet de le mettre en place sur n’importe quelle plate‑forme.

La bonne façon d’utiliser pip est de demander à l’exécutable Python pour lequel on veut installer un paquet de charger pip afin de réaliser cette installation :
/chemin/vers/python -m pip install nom_du_paquet --user --upgrade.
Les autres façons de faire que l’on peut trouver sur l’Internet (typiquement pip install nom_du_paquet) sont à éviter. Mais dans le cas d’un « environnement virtuel », on peut saisir python sans spécifier le chemin d’accès et utiliser la commande pip — tous deux sont issus de l’environnement virtuel.

Les options courantes :

  • --user indique d’installer le paquet dans un répertoire personnel de l’utilisateur, lié au Python concerné (cela évite d’aller écraser les paquets fournis par d’autres moyens) ; il n’est pas nécessaire de l’utiliser avec un environnement virtuel ;
  • --upgrade (ou -U) indique en plus de mettre à jour un paquet déjà installé vers la version la plus récente disponible.

Mais, même en utilisant l’option --user, si l’on installe un paquet pour une utilisation avec le Python 3 standard de la machine, ceci peut casser le fonctionnement de certains programmes (le paquet ainsi installé étant prioritaire par rapport à celui du système, s’il y a des incompatibilités… boum). La bonne façon de faire est d’utiliser des environnements virtuels (où l’on peut utiliser directement pip sans risque). C’est une bonne pratique à adopter dès le début afin de s’éviter des problèmes ultérieurs.

Sous Anaconda ou Miniconda avec conda

Le gestionnaire de paquets conda est développé pour Anaconda, disponible sur Windows, GNU/Linux et macOS.

La société qui le produit (ex‑Continuum Analytics, maintenant Anaconda) fournit des paquets déjà compilés pour de nombreuses bibliothèques Python (et autres langages), principalement dans le domaine des sciences et du calcul, mais pas uniquement. Certaines de ces bibliothèques ne sont pas toujours triviales à reconstruire, particulièrement sous Windows. L’adoption d’Anaconda peut être une solution si l’installation de certains paquets échoue avec d’autres distributions ; entre autres, par exemple, pour travailler localement sur des calepins (notebooks) Jupyter.

Notes :

  • les paquets absents de cette distribution peuvent être installés normalement avec pip ;
  • sous Windows, un menu d’application Anaconda Prompt est ajouté dans le groupe de programmes Anaconda, il permet d’accéder à conda même si celui‑ci n’est pas accessible dans les répertoires du PATH.

Conda gère un environnement base, celui par défaut correspondant à son installation de Python, mais peut aussi gérer des environnements supplémentaires avec leurs propres installations de Python et des paquets (avec les versions au choix).

~$ conda activate base
(base) ~$ which python
/home/login/.miniconda3/bin/python
(base) ~$ conda install numpy

… (liste de paquets à installer ou mettre à jour)…

Proceed ([y]/n) ? y

… (téléchargement, puis installation)…

Lorsqu’un paquet n’est pas disponible dans les dépôts de conda, on peut l’installer simplement à partir de PyPI avec pip :

(base)~$ conda install osc4py3
…
PackagesNotFoundError: The following packages are not available from current channels:

- osc4py3
…
(base)~$ python -m pip install osc4py3
(base)~$ python
Python 3.6.9 |Anaconda, Inc.| (default, Jul 30 2019, 19:07:31)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import osc4py3
>>>

À noter : certains IDE comme Pyzo donnent directement accès aux commandes conda et pip dans leur fenêtre d’interpréteur de commandes Python.

Mettre à jour les paquets Python

Avec le gestionnaire de paquets

Les paquets installés avec les gestionnaires habituels sous GNU/Linux (apt, yum, dnf, urpmi…) peuvent être mis à jour simplement avec ces mêmes gestionnaires. Ceux‐ci assurent la cohérence des versions installées (et il vaut mieux ne pas interférer avec ce qu’ils installent).

Avec pip

La commande python3 -m pip permet de mettre à jour un paquet particulier avec l’option --upgrade :

/chemin/vers/python -m pip install nom_du_paquet --user --upgrade

Mais il n’y a pas pour le moment de mise à jour automatique simple de l’ensemble des paquets installés avec pip. Celui-ci propose seulement un argument --outdated pour lister les paquets obsolètes. Avec un shell, en l’intégrant dans une expression en ligne de commande, il est toutefois possible de réaliser cette tâche :

/chemin/vers/python -m pip list --user --outdated --format freeze |
    cut -d= -f1 |
    xargs --no-run-if-empty /chemin/vers/python -m pip install --user --upgrade --progress-bar emoji

Sous macOS, retirer l’argument --no-run-if-empty de l’exemple ci‑dessus.

En cas de mise à jour des modules avec pip, il est possible d’enregistrer préalablement les versions des modules avant ou après la mise à jour :

python3 -m pip list --user --format freeze > ~/requirements_avant_pip_upgrade.txt

python3 -m pip list --user --outdated --format freeze |
    cut -d= -f1 |
    xargs --no-run-if-empty python3 -m pip install --user --upgrade --progress-bar emoji

python3 -m pip list --user --format freeze > ~/requirements_apres_pip_upgrade.txt

On peut ensuite visualiser les changements en affichant les différences entre les deux fichiers générés, par exemple avec l’outil meld :

meld ~/requirements_avant_pip_upgrade.txt ~/requirements_apres_pip_upgrade.txt

Et si besoin, en cas de problème, revenir aux versions précédentes :

python3 -m pip install --user -r ~/requirements_avant_pip_upgrade.txt

Avec conda

Pour les paquets fournis via Anaconda ou Miniconda, une simple commande exécutée dans l’environnement conda activé permet d’effectuer les mises à jour dans cet environnement :

~$ conda activate base

(base) ~$ conda update --all

Comment bien faire

Alors, utiliser pip est‑il dangereux ? Oui, sauf dans un environnement Python virtualisé. \o/ C’est l’objet du prochain article de cette série.

Tes astuces ?

N’hésite pas à partager tes expériences, tes astuces et tes interrogations. Quel est le meilleur interpréteur Python ? Pour quel usage ? Le plus performant ? Des différences de fonctionnement ? Avec quel système d’exploitation ?

Et n’oublie pas de nous donner un coup de main pour la quatrième partie de cette série de dépêches sur Python.
→ https://linuxfr.org/redaction/news/python-pour-la-rentree-2019-partie-4-environnements-virtuels-et-conteneurisation

Aller plus loin

  • # Prévenir vaut mieux que guerir

    Posté par  . Évalué à 1.

    Ce serait quand même bien de parler de virtualenv… Impossible de casser un système avec celui ci et surtout la capacité à utiliser des modules de différentes version pour gérer les problèmes de compatibilité.

  • # Pyenv

    Posté par  . Évalué à 1.

    Pour installer python sous linux, il y a pyenv.
    Ça permet d'installer n'importe quelle version de python dans l'espace utilisateur (de python 2 à 3 en passant par pypy et anaconda) de jongler entre ces versions, voir de spécifier quelle version utiliser en fonction du répertoire dans lequel on se trouve. En plus, il peut s'interfacer avec virtualenv. Comme il installe python dans l'espace utilisateur, on peut utiliser pip sans l'option --user.

    • [^] # La prochaine dépêche explique en détail Pyenv

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 septembre 2019 à 04:00.

      Oui, tout à fait. À l’origine, nous avions prévu de présenter pyenv dans cette troisième dépêche. Mais cette dépêche commençait à être très longue. Alors, nous avons déplacé le chapitre pyenv dans la dépêche suivante qui traite des environnements virtuels. Pour les curieux : https://linuxfr.org/redaction/news/python-pour-la-rentree-2019-partie-4-environnements-virtuels-et-conteneurisation#toc-outil-pyenv

      Pourrais-tu rajouter une explication de l'utilisation pyenv avec virtualenv ?

      Ne pas hésiter à vérifier l’exactitude de la prochaine dépêche et nous aider à améliorer sa qualité. Merci 😉

      Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

      • [^] # Re: La prochaine dépêche explique en détail Pyenv

        Posté par  . Évalué à 3.

        J'ai essayé une fois pour installer Python 3.7 sur Debian Stretch parce que j'étais coincé sur Python 3.5 mais ça a pas marché parce qu'il me manquait des libs pour compiler. En tout cas, c'est ce que j'ai compris.

        J'ai mal fait ou c'est normal ?

        Ca ne fonctionne que pour installer d'anciennes versions sur des distros récentes ?

        • [^] # Re: La prochaine dépêche explique en détail Pyenv

          Posté par  (site web personnel) . Évalué à 3.

          Oui, il est nécessaire d'installer des libs "développeur" pour installer compiler Python avec pyenv.

          Si tu veux lire en avance la prochaine dépêche :
          https://linuxfr.org/redaction/news/python-pour-la-rentree-2019-partie-4-environnements-virtuels-et-conteneurisation#toc-pyenv-pour-installer-tous-les-pythons

          N'hésite pas à tester, corriger, et même reformuler des paragraphes 😀

          Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

          • [^] # Re: La prochaine dépêche explique en détail Pyenv

            Posté par  . Évalué à 3.

            J'ai compris l'étape de compilation mais je crois que pour compiler PY3.7 sur Stretch, il me fallait installer des libs -dev depuis Buster ou Sid et même la libc de Buster/Sid donc j'ai laissé tomber (quitte à installer libc, autant passer à Buster et avoir le PY3.7 qui va avec, c'est d'ailleurs ce que j'ai fait).

            Mais peut-être que j'ai mal compris sur le moment et que j'aurais pu m'en sortir autrement avec la compilation.

            • [^] # Re: La prochaine dépêche explique en détail Pyenv

              Posté par  (site web personnel) . Évalué à 2.

              N'ayant pas installé compilé une version récente de Python (avec pyenv) sur une ancienne distribution GNU/Linux, je ne peux pas te répondre.

              De toutes façons, la version fournie compilée par la distribution est de meilleur qualité, testée, mieux optimisée (notamment LTO).

              L'outil pyenv c'est bien pour dépanner, mais on risque d'avoir des comportements un peu différents entre la version compilée par pyenv et la version fournie par sa distribution GNU/Linux, ne serait-ce que sur le temps d'exécution, le context switching des threads…

              Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

              • [^] # Re: La prochaine dépêche explique en détail Pyenv

                Posté par  . Évalué à 3.

                OK, merci.

                En l'occurrence, c'était un peu du dépannage. C'est pour faire tourner des outils de CI PY>=3.6 (black, en l'occurrence).

                Le code tourne sur 3.5 donc je peux développer, tester, utiliser. Mais les outils de CI ne tournaient pas sur ma machine, donc il me fallait pusher, attendre que ça tourne sur le serveur puis corriger.

  • # Une retouche trop rapide

    Posté par  (site web personnel) . Évalué à 6.

    Anaconda (Miniconda) et ActivePython ne sont que des distributions (section suivante) qui sont basées sur l'interpréteur standard CPython → ils ne devraient pas apparaître dans les interpréteurs.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Une retouche trop rapide

      Posté par  (site web personnel) . Évalué à 3.

      Oups, merci lolop pour ta relecture. Je me suis précipité à soumettre la dépêche aux modérateurs car la rentrée s'acchève bientôt et que nous avons d'autres dépêches Python dans le tuyau…

      J'en profite pour un appel à contributions : nous avons besoin de votre aide pour completer/relire/corriger les dépêches Python en courses de résaction. 🤩 Merci 😘

      Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

  • # Autre dépêche sur Pyston, CPython, PyPy...

    Posté par  (site web personnel) . Évalué à 2.

    Une dépêche de 2014 présente CPython, IronPython, Jython, PyPy, Numba, Unladen Swallow et le dernier né de l'époque : Pyston.
    https://linuxfr.org/news/un-projet-de-vm-python-chez-dropbox-et-etat-des-lieux-des-autres-vm

    Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

    • [^] # Re: Autre dépêche sur Pyston, CPython, PyPy...

      Posté par  . Évalué à 3.

      • CPython
      • IronPython dernière version 2.7.9 l'an dernier. Ils annonçaient travailler sur IronPython3 pour passer à python 3, mais l'activité du dépôt a l'air… calme
      • Jython on en parlait dans l'autre dépêche dernière version 2.7.1 en 2017 toujours pas de python 3 à l'horizon
      • PyPy la version 7.1.1 gère péniblement python 3.6
      • Numba bouge encore, c'est à rapproché de pythran je pense
      • Unladen Swallow mort depuis bien longtemps
      • Pyston pas de version depuis 2017 le dépôt semble mort, pas de compatibilité 3.x

      Et si je ne me trompe pas, ils ont tous des difficulté à gérer les fameuses bibliothèques en C ultra optimisées™ (sauf Numpy sur lequel ils ne se permettent pas de faire l'impasse). Beaucoup de monde essaie de pleins de manière de réimplémenter python, mais au final ça a vraiment l'air ingérable. Il y a un projet et demi qui ont l'air pérennes et encore ils ont des limitations à droite à gauche.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Commentaire supprimé

    Posté par  . Évalué à 1. Dernière modification le 26 septembre 2019 à 13:15.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Bazar!

    Posté par  . Évalué à 0.

    La richesse des libs python permet de faire pas mal de choses rapidement, mais en illustration je suggère la vision de la fosse remplie de serpents d'un épisode d'Indiana Jones!

    En réalité, les multiples interpréteurs (et leur obésité qui en arrive à les faire peser plus lourd que le système complet qui les fait tourner), les possibilités de casse système ou au mieux limitées à l'utilisateur induites par les chemins multiples d'installation de paquets, ce qui amène aux environnements virtuels (et autant de doublons) cela me rappelle un truc: Le syndrome Java!

    Ce que j'appelle le syndrome Java, c'est que quasiment chaque appli codée en Java embarque désormais le plus souvent sa VM et dépendances pour éviter (même pas toujours) les ennuis/instabilités. Un gâchis faramineux.

    Il n'y a bien que sous Androïd que Google semble avoir réussi, vu de (pas trop, j'espère?) haut tout du moins, à bien cadrer l'affaire. Au prix d'un applicatif bien lent tout de même, surtout à avoir snobbé Jazelle pour ne pas se lier pieds et poings à l'architecture ARM.

    • [^] # Re: Bazar!

      Posté par  . Évalué à 2.

      Bon je me lance…

      La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.

      Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.

      le développeur

      Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).

      C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.

      Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,…

      opérationnel/admin sys

      Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.

      Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc

      (évidemment j'exagère)

      Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Bazar!

        Posté par  . Évalué à 0.

        On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.

        Rien de plus simple, en fait.

        Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.

        Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!

        En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…

        • [^] # Re: Bazar!

          Posté par  . Évalué à 1.

          Je ne suis pas d'accord.

          Dans un monde parfait oui le versionnement suffirait, mais personne n'est capable de garantir qu'un changement ne va pas casser une compatibilité. Donc non changer une micro n'est jamais anodin pour un projet.

          De même pour la stabilité des API l'esprit humain n'est pas capable de lire l'avenir donc tu n'a aucune garanti que l'API que tu décris est stable ou non. Ce qui tiens un peu mieux que les autres c'est les API qui font le minimum de choses.

          En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…

          J'ai rien compris… Pour la première partie je sais pas trop ce que tu veux dire. Pour la seconde, euh… Tu connais beaucoup de logiciels en C qui utilisent que la libc (qui ne permet pas de créer de thread) ? Ou qui n'utilisent que la libc + les appels système (ça te permet d'avoir des threads) ?

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Bazar!

            Posté par  . Évalué à 0.

            Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.

            Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.

            Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.

            • [^] # Re: Bazar!

              Posté par  . Évalué à 1.

              Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.

              Non malloc(3) en est l'exemple le plus criant. Il y a un tas d'API très simple qui ont posé problèmes et qui se sont donc fait remplacer ou ont dû évoluer.

              Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.

              J'adore les injonctions bien péremptoire comme ça. Tu as la vision totale et complète de ce qu'est un projet informatique de manière générale et tu sais ce qui est bien de ce qui ne l'est pas. Tous ceux qui n'allant pas dans ton sens étant dans l'erreur…

              On est complètement dans la dichotomie de « la cathédrale et du bazar ». Les méthodes agiles servent à donner un cadre au bazar. Elles sont extrêmement pertinentes quand le demandeur du projet a du mal à formaliser son besoin. Il y a d'autres endroit où la cathédrale fait du sens, je ne remet pas du tout en cause ça.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Installation sur Windows avec Chocolatey

    Posté par  . Évalué à 1.

    Chocolatey permet d'installer Python (et des centaines d'autres logiciels) avec une simple ligne de commande : choco install python pour Python 3.7.4, choco install python --pre pour Python 3.8.0-rc0 et choco install python2 pour Python 2.7.16.

    Chocolatey est un gestionnaire de paquets pour Windows qui s'installe à l'aide d'une seule ligne de commande.

    Cette signature est publiée sous licence WTFPL

Suivre le flux des commentaires

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