Python — partie 7 — Environnements virtuels

Posté par  (site Web personnel) . Édité par lolop, Ysabeau, Axone, bobble bubble, tisaac, Di3s3L, gusterhack et ted. Modéré par Ysabeau. Licence CC By‑SA.
Étiquettes :
34
6
mai
2021
Python

Cette septième dépêche présente les environnements virtuels Python et ses alternatives comme la conteneurisation, le tout avec plein d’astuces et de conseils pour bien s’en sortir. 🚀 🐍

Le logo de Python est entouré de petites icônes symbolisant la variété des domaines où s’applique Python, et, à droite, un joyeux barbu se tient derrière un écran d’ordinateur qui affiche « partie = 7, "Env. Virtuels" \n print(partie) »

Sommaire

Environnement Python virtualisé, quésaco

L’idée est d’avoir une installation d'une version de Python et de paquets spécifiques pour chacun de ses projets, avec une maîtrise des versions et des dépendances, et qui n'interfère pas avec l'installation standard des paquets par le système. Et le tout versionné avec le code source de son projet. Ainsi nous avons une installation équivalente pour les différents développeurs et la production.

Quelques outils pour créer des environnements virtuels :

  • virtualenv, pour Linux / macOS / Windows, est l’ancêtre, continue d’évoluer et toujours très utilisé (article en français) ;
  • venv est l'intégration de virtualenv dans le cœur de Python, mais il est paradoxalement moins utilisé que son ancêtre virtualenv car venv est plus basique ;
  • virtualenvwrapper est un ensemble de commandes bien pratiques pour étendre les possibilités de virtualenv tout en le gardant simple d'usage, avec des portages pour Windows (shell cmd et PowerShell) ;
  • pew est aussi complet et plus simple que virtualenvwrapper ;
  • pipenv (Linux / macOS / Windows) unifie pip et virtualenv afin de simplifier d'avantage la gestion des environnements virtuels et la gestion des dépendances (versions) et sera abordé dans la prochaine dépêche ;
  • conda, pour Linux / macOS / Windows, gère aussi des environnements virtuels, et propose un certain nombre de bibliothèques pré-paquagées en supplément à pip.

Nous allons également présenter pyenv pour l'installation de différentes versions de Python et l'activation rapide d'une des différentes installations de Python pour un même projet.

L'ancêtre virtualenv

L'outil historique donc, encore très utilisé et qui sert de base pour certaines surcouches. Il est généralement déjà paquagé dans les distributions Linux, et est donc installable par votre gestionnaire de paquets. Sinon, à installer avec pip :

/usr/bin/python3 -m pip install --user --upgrade virtualenv

L'environnement virtuel se crée dans un sous-répertoire, nommé .env-truc dans l'exemple ci-dessous :

$ cd /chemin/vers/le/projet
$ /usr/bin/python3 -m virtualenv .env-truc
  No LICENSE.txt / LICENSE found in source
New python executable in /tmp/truc/.env-truc/bin/python3
Also creating executable in /tmp/truc/.env-truc/bin/python
Installing setuptools, pip, wheel...
done.

ou directement :

/usr/bin/python3 -m virtualenv /chemin/vers/le/projet/.env-truc

Le répertoire .env-truc contient tout ce qui est nécessaire à l’interpréteur Python avec ses commandes et ses bibliothèques. Cet environnement de travail est indépendant des paquets déjà installés sur la machine :

$ $ tree -d -L 4 .env-truc/
.env-truc/
├── bin
├── include
│   └── python3.7m -> /usr/include/python3.7m
├── lib
│   └── python3.7
│       ├── collections -> /usr/lib64/python3.7/collections
│       ├── config-3.7m-x86_64-linux-gnu -> /usr/lib64/python3.7/config-3.7m-x86_64-linux-gnu
│       ├── distutils
│       │   └── __pycache__
│       ├── encodings -> /usr/lib64/python3.7/encodings
│       ├── importlib -> /usr/lib64/python3.7/importlib
│       ├── lib-dynload -> /usr/lib64/python3.7/lib-dynload
│       ├── __pycache__
│       └── site-packages
│           ├── pip
│           ├── pip-19.2.3.dist-info
│           ├── pkg_resources
│           ├── __pycache__
│           ├── setuptools
│           ├── setuptools-41.2.0.dist-info
│           ├── wheel
│           └── wheel-0.33.6.dist-info
└── lib64 -> lib

Pour entrer dans le shell de cet environnement isolé :

  • Sous GNU/Linux et macOS : source /chemin/vers/le/projet/.env-truc/bin/activate
  • Sous Windows : C:\\chemin\vers\le\projet\.env\bin-truc\activate\Scripts\activate.bat

Le prompt indique le nom de l'environnement virtuel:

<mon-prompt> $ cd /chemin/vers/le/projet
<mon-prompt> $ source .env-truc/bin/activate
(.env-truc) <mon-prompt> $ type -a python3
python3 is /chemin/vers/le/projet/.env-truc/bin/python3
python3 is /usr/bin/python3

Installer les dépendances avec pip sans affecter les autres installations Python de la machine. Attention à bien utiliser python3 et non pas /bin/usr/python3 :

(.env-truc) <mon-prompt> $ python3 -m pip install requests
Collecting requests
  Downloading https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl (57kB)
     |████████████████████████████████| 61kB 5.4MB/s
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests)
  Downloading https://files.pythonhosted.org/packages/e0/da/55f51ea951e1b7c63a579c09dd7db825bb730ec1fe9c0180fc77bfb31448/urllib3-1.25.6-py2.py3-none-any.whl (125kB)
     |████████████████████████████████| 133kB 10.0MB/s
Collecting chardet<3.1.0,>=3.0.2 (from requests)
  Downloading https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl (133kB)
     |████████████████████████████████| 143kB 10.5MB/s
Collecting idna<2.9,>=2.5 (from requests)
  Downloading https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl (58kB)
     |████████████████████████████████| 61kB 9.4MB/s
Collecting certifi>=2017.4.17 (from requests)
  Using cached https://files.pythonhosted.org/packages/18/b0/8146a4f8dd402f60744fa380bc73ca47303cccf8b9190fd16a827281eac2/certifi-2019.9.11-py2.py3-none-any.whl
Installing collected packages: urllib3, chardet, idna, certifi, requests
Successfully installed certifi-2019.9.11 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.6

Sortir de l’environnement virtuel :

(.env-truc) <mon-prompt> $ deactivate
<mon-prompt> $

On peut donc créer un environnement virtuel pour chacun des projets, ou même plusieurs environnements virtuels pour un projet : un pour être iso prod, un pour les tests de nouvelles libs…

Cela prend un peu de place, surtout dans .env-truc/lib64/python3.7/site-packages (les dépendances) car pour le reste ce sont des liens symboliques.

$ du -hsc .env-truc/* | sort -h
0       .env-truc/include
0       .env-truc/lib64
76K     .env-truc/bin
16M     .env-truc/lib
16M     total

venv est fourni de base avec Python

L'outil venv est similaire à son ancêtre et s'utilise avec la même approche. Création :

<mon-prompt>$ cd /chemin/mon/projet
<mon-prompt>$ /usr/bin/python3 -m venv .env-truc

Activation :

<mon-prompt>$ . .env-truc/bin/activate
(.env-truc) <mon-prompt>$ type -a python3
python3 is /tmp/truc/.env-truc/bin/python3
python3 is /usr/bin/python3

Installation des dépendances :

(.env-truc) <mon-prompt>$ python3 -m pip install requests
Collecting requests
  Using cached https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl
Collecting chardet<3.1.0,>=3.0.2 (from requests)
  Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Collecting certifi>=2017.4.17 (from requests)
  Using cached https://files.pythonhosted.org/packages/18/b0/8146a4f8dd402f60744fa380bc73ca47303cccf8b9190fd16a827281eac2/certifi-2019.9.11-py2.py3-none-any.whl
Collecting idna<2.9,>=2.5 (from requests)
  Using cached https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests)
  Using cached https://files.pythonhosted.org/packages/e0/da/55f51ea951e1b7c63a579c09dd7db825bb730ec1fe9c0180fc77bfb31448/urllib3-1.25.6-py2.py3-none-any.whl
Installing collected packages: chardet, certifi, idna, urllib3, requests
Successfully installed certifi-2019.9.11 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.6
You are using pip version 19.0.3, however version 19.2.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Désactivation :

(.env-truc) <mon-prompt>$ deactivate

Espace occupé :

<mon-prompt>$ du -hsc .env-truc/* | sort -h
0       .env-truc/include
0       .env-truc/lib64
4.0K    .env-truc/pyvenv.cfg
36K     .env-truc/bin
14M     .env-truc/lib
14M     total

La documentation officielle de la Python Software Foundation est en français : https://docs.python.org/fr/dev/library/venv.html

virtualenvwrapper pour étendre virtualenv

Le projet virtualenvwrapper permet de ne plus se soucier du répertoire où se trouvent les environnements virtuels. Ce projet fonctionne et ajoutant des commandes au dessus de la commande virtualenv pour :

  • organiser les environnements virtuels où que l’on se trouve dans l’arborescence des répertoires ;
  • simplifier la création/copie/suppression des environnements virtuels ;
  • passer d’un environnement virtuel à un autre (super utile) ;
  • compléter la ligne de commande, avec touche [Tab], selon les environnements virtuels disponibles ;
  • étendre davantage ces commandes avec un système d’extensions (plugins) ;
  • fournir des crochets (hook) personnalisables.

Installation:

/usr/bin/python3 -m pip install --user --upgrade virtualenvwrapper

Ajouter dans le ~/.bashrc (ou autre fichier de configuration équivalent) :

export WORKON_HOME=~/.virtualenvs
mkdir -p $WORKON_HOME
source ~/.local/bin/virtualenvwrapper.sh

Les commandes suivantes ont le même effet quel que soit le répertoire où l’on se trouve :

  • mkvirtualenv {nom_env} pour créer un environnement virtuel (avec virtualenv) dans le dossier $WORKON_HOME (~/.virtualenvs) ;
  • workon {nom_env} pour activer un environnement virtuel ;
  • rmvirtualenv {nom_env} pour supprimer l’environnement virtuel.

Les options de mkvirtualenv sont les mêmes que pour la commande virtualenv.

pew dépasse virtualenvwrapper

Installation :

/bin/usr/python -m pip install --user --upgrade pew

Par rapport au projet virtualenvwrapper, le nom des commandes pew (tout comme le nom du projet) sont plus courtes et élégantes. Les commandes pew sont aussi plus nombreuses :

Équivalence virtualenvwrapper pew
$WORKON_HOME par défaut ~/.virtualenvs ~/local/share/virtualenvs
Lister les env workon pew ls
Créer un env mkvirtualenv <nom> pew new <nom>
Supprimer un env rmvirtualenv <nom> pew rm <nom>
Activer un env workon <nom> pew workon <nom>
Aller dans le site-packages cdsitepackages cd $(pew sitepackages_dir)
Exécuter sans activer l'env (aucune) pew in <nom> <commande>
Exécuter dans tous les env (aucune) pew inall <commande>
Dupliquer un env (aucune) pew cp <nom> <destination>
Modifier PYTHONPATH (aucune) pew add path
Créer un env temporaire (aucune) pew mktmpenv
Choisir le dossier par défaut (aucune) pew setproject path

 
De plus, pew ne nécessite pas de modifier le .bashrc car pew ouvre un nouveau shell. Donc, la sortie de l'environnement virtuel se fait avec exit ou la combinaison des touches [Ctrl]+[D].

L'inconvénient de pew est de nécessiter l'exécution de l'interpréteur Python pour chaque commande lancée, ce qui alourdit son utilisation et peut rajouter une latence par rapport à virtualenvwrapper, mais cela reste négligeable pour la plupart des machines modernes.

conda les gère les aussi

La commande conda d'Anaconda et de Miniconda permet, en plus de la gestion des paquets, de gérer des environnements virtuels Python. On dispose de trois sous-commandes de base :

  • conda create pour créer un environnement virtuel,
  • conda activate pour l'utiliser,
  • conda deactivate pour cesser de l'utiliser

Exemple :

~$ conda create -n testenv1
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /home/login/.miniconda3/envs/testenv1

Proceed ([y]/n)? y
…
~$ conda activate testenv1
(testenv1) ~$ 

Par défaut l'environnement virtuel reprend la version de Python standard du système. Mais il est possible de spécifier une version de Python à utiliser :

~$ conda create -n testenv2 python=3.7
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /home/login/.miniconda3/envs/testenv2

  added / updated specs:
    - python=3.7

…(plus de choses à installer)…

Proceed ([y]/n)? 

…(téléchargement et installation)…
~$ conda activate testenv2
(testenv2) ~$ which python
/home/login/.miniconda3/envs/testenv2/bin/python
(testenv2) ~$ which pip
/home/login/.miniconda3/envs/testenv2/bin/pip

On remarque qu'une fois l'environnement virtuel activé, la commande pip peut être utilisée directement, de façon saine sans risque de dommages pour votre système.

C'est nul les environnements virtuels !

Des experts Pythons trouvent que les environnements virtuels complexifient inutilement l'utilisation de Python et qu'ils dénaturent la philosophie de simplicité. Ces experts réfléchissent avec la PSF pour trouver une solution plus simple en s'inspirant des écosystèmes Ruby, Node.js Deno, Rust (cargo), Go

En attendant, pour avoir des espaces de développement indépendants entre ses projets, nous avons des alternatives.

PYTHONUSERBASE

La façon la plus basique est d'invoquer pip avec la variable d'environnement PYTHONUSERBASE.

Installer les dépendances :

$ cd /chemin/mon/projet
$ PYTHONUSERBASE=$PWD/.pip-env
$ /usr/bin/python3 -m pip install --user --upgrade requests

Tester son application :

$ cd /chemin/mon/projet
$ PYTHONUSERBASE=$PWD/.pip-env 
$ PYTHONPATH=$PWD 
$ /usr/bin/python3 -m <mon-projet>

ou juste un script :

$ PYTHONUSERBASE=$PWD/.pip-env 
$ /usr/bin/python3 <mon-script.py>

Les variables d'environnement peuvent aussi être mises dans un fichier shell et activées avec source /chemin/mon/projet/activate.sh. Mais bon… on réinvente un peu la roue venv !

export PYTHONUSERBASE=/chemin/mon/projet/.pip-env
export PYTHONPATH=/chemin/mon/projet

Conteneur

Les habitué·e·s des conteneurs, comme Docker, ont tendance à se créer une image avec uniquement la version Python de leur choix, puis de travailler dans un shell de ce conteneur pour y installer les dépendances nécessaires.

De toutes façons, dans ces organisations, les applications sont livrées dans des conteneurs. Pourquoi ne pas utiliser le même environnement qu'en production ?

Attention quand même à bien configurer son image pour conserver ses changements. 😁

Machine Virtuelle

On peut aussi carrément utiliser une machine virtuelle pour isoler un environnement Python. C'est plus lourd qu'un conteneur, mais bon, on faisait comme ça il n'y a pas si longtemps. Sans oublier, que de nombreuses organisations déploient encore leurs applications avec une installation classique. Alors, pourquoi pas utiliser un environnement similaire à celui de la production ?

L'outil vagrant peut aider a scripter la création de sa VM. On peut créer plusieurs VMs sur sa machine (en local) et/ou dans les nuages (cloud)

AppVM

L'Application Machine Virtuelle (AppVM), concept du système d'exploitation Qubes OS, permet d'isoler chaque application.

Gestionnaire de paquet de nouvelle génération

Le gestionnaire de paquets Nix est fourni avec la commande nix-shell pour activer un shell en spécifiant les dépendances souhaitées.

Le gestionnaire de paquets GNU Guix, inspiré de Nix, offre une solution similaire avec la commande guix environment.

Remerciements

Merci à tous les contributeurs de cette dépêche, et notamment à lolop, Ysabeau et Sam & Max. lolop sʼest beaucoup investi dans la rédaction et lʼorganisation des dépêches 🤩, Ysabeau a initié les illustrations de cette série de dépêches 🤩 🎨 🖌 et Sam m'autorise à copier les articles du site http://sametmax.com 🤩 📄 📝.

Extrait du courrier de Sam :

Bonjour Oliver,

Je te donne explicitement lʼautorisation de copier, modifier et publier les articles, partiellement, ou en totalité, et de mettre le résultat sous licence CC0. Cette autorisation sʼétend à l'écriture de posts inspirés d'articles du blog par Sam ou Max, avec ou sans reprise de contenu, et te laisse libre de piocher dans le texte, les codes et contenus graphiques que nous avons produit, mais ne peut concerner les articles invités ou les images piochées sur le net sur lesquels nous n'avons pas les droits. Les articles invités peuvent néanmoins être repris sous CC-BY, bien entendu.

[…]

Licence

Cette dépêche est publiée sous licence CC0 (sous domaine publique dans les pays où cela est possible) pour permettre de la recopier, modifier, réutiliser et republier sans obligation de citer ses auteurs. Sauf la loi de certains pays, comme la France, qui oblige quand même à citer les auteurs. Au moins, cela montre l'intention des auteurs à autoriser le plagiat.

Tes astuces ?

N'hésite pas à partager tes expériences, tes astuces et tes interrogations.

Et n’oublie pas de nous donner un coup de main pour la suite de cette série de dépêches sur Python. Par exemple, Python pour Noël 202X— partie 9 — empaquetage.

Aller plus loin

  • # Où placer ses environnements virtuels et comment les nommer ?

    Posté par  . Évalué à 9 (+7/-0). Dernière modification le 06/05/21 à 14:22.

    J'utilise venv sur l'ensemble de mes petits projets perso et ayant tout appris sur le tas, je me demande où créer le dossier qui va contenir l'environnement virtuel et comment le nommer.

    Aujourd'hui je crée le venv dans le dossier où est aussi le code, dans un dossier ".venv". Et j'exclue ce dossier dans mon .gitignore

    Est-ce une bonne pratique ? Y a-t-il d'autres usages ? Quel sont le pour et le contre des différentes méthodes ?

    J'ai lu quelque part que certaines personnes font un dossier dans leur home qui contient l'ensemble de leurs environnements virtuels, mais ça me semble être peu pratique pour retrouver le bon environnement à activer pour le bon projet.

    • [^] # Re: Où placer ses environnements virtuels et comment les nommer ?

      Posté par  . Évalué à 3 (+2/-0).

      … je fais pareil, je ne suis pas très fan non plus des venvs dans un dossier commun - Quand on a 40 projets python environ, c'est plus facile de retrouver ses petits effectivement. De plus, c'est plus facile de recréer un venv localement, en cas de montée de version de python par exemple.

      Courage !

    • [^] # Re: Où placer ses environnements virtuels et comment les nommer ?

      Posté par  . Évalué à 2 (+1/-0).

      Je fais pareil avec mise à jour régulière du fichier requirements (ou requirements.txt sur windows) que je mets à la racine du projet sous gestion de conf (fossil dans mon cas).

    • [^] # Re: Où placer ses environnements virtuels et comment les nommer ?

      Posté par  . Évalué à 2 (+2/-0).

      Je mettais aussi mes environnements virtuels dans le dossier du projet avant, mais j'ai eu un problème une fois où j'avais un chemin assez long.
      Les scripts créés dans l'environnement virtuel (pip, pip3, etc) référencent l'interpréteur local avec un truc du genre #!/venv/bin/python.
      Problème si ce chemin est trop long, ça coince et ça sort des erreurs bizarres.

      Je ne sais pas si tous les environnements virtuels ont le même problème, mais ça pourrait expliquer pourquoi il est plus intéressant de placer ses environnements dans son home.

    • [^] # Re: Où placer ses environnements virtuels et comment les nommer ?

      Posté par  . Évalué à 5 (+5/-0).

      Pour ma part, je suis contre les répertoires nommé ".venv".
      C'est super c'est caché, mais quand quelqu'un travaille avec vous il ne voit pas le fichier caché en question.
      python -m venv venv c'est mieux :)
      Au moins c'est clair et explicite, et puis perso si je reviens dessus dans 2 mois, je le vois tout de suite!

    • [^] # Re: Où placer ses environnements virtuels et comment les nommer ?

      Posté par  . Évalué à 3 (+2/-0).

      Je pense qu'il n'y a pas vraiment de meilleure approche car l'organisation choisie va dépendre du flux de travail utilisé.

      J'ai lu quelque part que certaines personnes font un dossier dans leur home qui contient l'ensemble de leurs environnements virtuels, mais ça me semble être peu pratique pour retrouver le bon environnement à activer pour le bon projet.

      L'approche d'un dossier contenant tous les environnements virtuels est celle imposée par virtualenvwrapper et pew On retrouve facilement le bon environnement à activer en le nommant correctement : je conseille de lui donner le même nom que le projet…

      Aujourd'hui je crée le venv dans le dossier où est aussi le code, dans un dossier ".venv". Et j'exclue ce dossier dans mon .gitignore

      En fait c'est pareil : est-ce que tu préfères, dans ta matrice de travail, que les environnements Py soient en abscisses ou en ordonnées :-) Dans l'approche précédente, je mettrai par exemple les sources dans un sous-répertoire $venv/src et c'est ce dernier qui sera versionné. Le principal avantage dans ce cas, comparé à l'autre organisation, est de ne pas polluer le .gitignore (je trouve que c'est une mauvaise pratique et un mauvais signe quand on y retrouve des trucs relatifs à son organisation perso quand on doit travailler en équipe)

    • [^] # Re: Où placer ses environnements virtuels et comment les nommer ?

      Posté par  . Évalué à 4 (+3/-0).

      Pour ma part j'utilise virtualenv avec direnv pour chaque projet.
      ```
      python -m venv --system-site-packages .venv

      cat < "EOF" >.envrc
      export VIRTUAL_ENV=$(pwd)/.venv
      export PATH=$VIRTUAL_ENV/bin:$PATH
      EOF

      direnv allow
      ```
      Et maintenant quand j'arrive dans ce répertoire ou un de ses sous-répertoires, le virtualenv est automatiquement activé. De la même manière il est automatiquement désactivé si je quitte ce répertoire.

  • # 'source' <=> '.'

    Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

    Il me semble que source et . sont strictement équivalents. Du coup, utiliser l'un avec virtualenv et l'autre avec venv pour faire strictement la même chose peut être source de confusion.

    En outre, je suppose que venv est également disponible sous Windows et que, à l'instar de virtualenv, l'activation se fait alors par lancement d'un activate.bat

    Le toolkit Atlas, la bibliothèque légère et facile à utilser pour débuter avec la programmation d'interfaces graphiques… (voir 'site Web personnel").

  • # Import from 'le réseau des méchants'

    Posté par  . Évalué à 6 (+4/-0).

    Je vais sur Wikipédia, et je vois un exemple qui marche avec deno :

    // Imports `serve` from the remote Deno standard library, using URL.
    import { serve } from "https://deno.land/std@v0.21.0/http/server.ts";
    
    // `serve` function returns an asynchronous iterator, yielding a stream of requests
    for await (const req of serve({ port: 8000 })) {
        req.respond({ body: "Hello, World!\n" });
    }

    Et ça dit :

    When running this program, Deno will automatically download and cache the remote standard library files, and compile the code.

    OK. Ça choque personne en vrai ? J'imagine que deno vérifie le certificat, mais quand même, c'est extrêmement fragile. Et moi, dans ma boîte, j'ai un environnement CI/CD qui évidemment n'accède pas à Internet. C'est la base de la sécurité de la chaîne d'approvisionnement.

    Je sais que Rust et Go font pareil. C'est pas une bonne raison. Je suis d'accord pour dire que c'est moderne, et je pense que c'est une mauvaise idée. J'aurais plutôt vu un truc genre :

    • Dans le code import { serve } from 'std@v0.21.0/http/server.ts'
    • Dans la conf du projet un truc genre default_repository: https://deno.land/

    Et si on veut mettre autre chose, on peut.

  • # Poetry et PEP 582

    Posté par  (site Web personnel) . Évalué à 9 (+8/-1).

    Depuis quelque temps, il y a Poetry qui a le vent en poupe, il gère tout ce qu'il faut pour le packaging, la publication, et l'exécution (y compris les environnements virtuels dont on parle ici). Je n'y suis pas encore passé moi même donc je n'ai pas de retour d'expérience, mais ça semble être vraiment bien.

    J'avais aussi vu passer un outil qui utilisait __pypackages__ (cf. PEP 582) et qui n'avait donc pas besoin d’environnement virtuel. J'ai oublié le nom, mais après une recherche je suis tombé sur PDM, c'était peut-être celui-là.

    • [^] # Re: Poetry et PEP 582

      Posté par  (site Web personnel) . Évalué à 2 (+1/-0).

      J’utilise Poetry depuis une petite année et ça a tout changé pour moi. Je ne suis pas développeur professionnel, mais je programme pas mal pour mon travail (recherche en science des données on va dire). Je n’utilise plus que ça et fait tous mes développements python avec. J'ai essayé virtualenv et pipenv avant, mais poetry c'est pour moi "as it must be".

  • # page de la partie 5 en 403 ?

    Posté par  . Évalué à 2 (+0/-0).

    Je voulais lire la "Python — partie 5 ― Nix (et Guix)" mais le lien https://linuxfr.org/news/python-pour-noel-202x-partie-5-nix-et-guix part en 403 :(

  • # Nommer ses venv, c'est bien

    Posté par  . Évalué à 3 (+2/-0). Dernière modification le 08/05/21 à 09:54.

    Le souci de python3 -m venv .venv c'est qu'il crée un venv qui s'appelle .venv, donc le prompt ressemble à (.venv) mdk@seraph:/tmp.

    Ça se personalise avec --prompt mais je trouve ça lourd python3 -m venv --prompt nom_du_projet .venv, on pourrait écrire python3 -m venv --prompt "$(basename "$PWD")", l'avantage c'est que ça traîne dans l'historique, mais je préfère encore m'en faire une fonction bash, comme ça je peux activer le venv en même temps :

    venv () 
    { 
        deactivate 2> /dev/null;
        if ! [[ -d .venv ]]; then
            python$1 -m venv --prompt "$(basename "$PWD"))(py$(python$1 --version | cut -d' ' -f2)" .venv;
        fi;
        source .venv/bin/activate
    }

    Les petits $1 qui traînent c'est parce que j'ai plusieurs version de Python (3.4, 3.5, 3.6, 3.7, 3.8, 3.9, et 3.10 là), installés avec make altinstall donc je peux toucher le Python de ma Debian via python ou un Python compilé à la main via python3.x.

    Demo time :

    $ mkdir petitprojet
    $ cd petitprojet/
    $ venv
    (petitprojet)(py3.9.4) $

    ou

    $ venv 3.6
    (petitprojet)(py3.6.12) $

    Pour ceux qui veulent comme moi plein plein de versions de Python, j'avoue aussi utiliser des fonctions bash pour ça. Elle est plus compliquée qu'elle pourrait : j'aime bien me compiler des beta, et j'aime bien avoir --with-pydebug mais uniquement après la 3.8, car avant la 3.8 le build de debug n'est pas compatible avec le build normal (pas pratique pour les extensions compilées).

    compile_python () 
    { 
        local PY_VERSION="$1";
        local BETA="$2";
        local FLAGS="";
        if dpkg --compare-versions "$PY_VERSION" ge 3.8.0; then
            FLAGS="--with-pydebug";
        fi;
        local URL="https://www.python.org/ftp/python";
        ( cd /tmp;
        wget -qO- $URL/$PY_VERSION/Python-$PY_VERSION$BETA.tgz | tar -xzf - || ( echo "Version not found, check on $URL." );
        [ -d Python-$PY_VERSION$BETA ] && ( cd Python-$PY_VERSION$BETA;
        ./configure $FLAGS --prefix=$HOME/.local/ && make -j $(nproc) && make altinstall ) && rm -r Python-$PY_VERSION$BETA )
    }

    et tant qu'a faire :

    compile_all_pythons()
    {
        compile_python 3.5.10 &
        compile_python 3.6.12 &
        compile_python 3.7.10 &
        compile_python 3.8.10 &
        compile_python 3.9.5 &
        compile_python 3.10.0 b1 &
        wait
    }

Envoyer un commentaire

Suivre le flux des commentaires

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