Définition d’un environnement virtuel

un environnement virtuel permet de développer du code source dans un espace en partie séparé de la machine hôte dans lequel on va pouvoir charger les paquets qui sont importants pour l’exécution du code source.

environnement virtuel pour Python

créer et activer un environnement virtuel avec la commande venv

virtualenv est installé d’office dans Python. Pour l’utiliser, il faut passer une commande depuis le terminal du système.

Le terminal sous GNU/Linux par défaut est bash. On peut l’ouvrir avec la commande Ctrl Alt+t

Pour Windows :

On peut ouvrir un terminal à partir du menu démarrer en entrant CMDou powershell ou bien se positionner à l’endroit où l’on souhaite créer un environneemnt virtuel et faire un clic droitet dans le menu qui s'ouvre sélectionnerOuvrir dans le terminal`.

une fois que le terminal est ouvert, il faut entrer la commande suivante :

python -m venv venv

Le premier venv correspond à la fonction virtualenv qui va créer l’environnement. Le second correspond au nom qu’on va donner à cet environnement. On pourrait lui donner un autre nom ; mais il est utile de garder venv pour signaler aux réutilisateurs qu’il s’agit d’un environnement virtuel.

une fois cet environnement créé, il faut encore l’activer. La disposition de l’environnement est différent sous Linux et sous Windows. Les commandes à passer seront donc elles aussi différentes

Pour activer l’environnement virtuel (toujours appelé venv ici) :

• pour GNU/Linux ou MacOs :

source venv/bin/activate

• pour Windows :

./venv/Scripts/activate

Si cela fonctionne, l’invite de commande du terminal doit désormais commencer par (venv) suivi du nom de l’usager.

A partir de ce moment, chaque fois que la commande pip install <nom d’une librairie> sera passée, la librairie sera installée dans l’environnement virtuel et pas sur le système.

la commande freeze

Avant de livrer son code, il est important de faire l’inventaire des librairies utilisées et pour chacune d’indiquer leur version. C’est l’objet de la commande pip freeze.

Cette commande permet de geler l’état d’un ensemble de dépendances dans un fichier qui par conventions s’appelle requirements.txt ; là encore il est déconseillé de changer le nom de de ce fichier pour bien signaler que c’est ici qu’on trouvera la liste des dépendances du code source.

Dans le terminal (une fois l’environnement virtuel activé), passer la commande suivante :

pip freeze > requirements.txt

Le fichier requirements.txt est créé avec les dépendances de premier niveau nécessaires pour l’exécution du script, ainsi que le détail de leur version.

Contrairement à l’ensemble du dossier comportant les librairies, ce fichier requirements.txt devra accompagner votre code source là où celui-ci sera partagé et archivé (forge et archive Software Heritage)

environnement virtuel pour R

Les environnements virtuels sous R fonctionnent de manière sensiblement différente. On les crée depuis le terminal de R ou la console de Rstudio.

Créer un environnement virtuel avec R requiert l’installation préalable du package Renv :

install.packages("renv")

Puis on passe la commande renv::init() pour initialiser l’environnement. Lorsqu’on a installé un premier jeu de packages depuis le CRAN ou ailleurs, on peut, comme pour freeze (voir plus haut) générer dans un fichier de configuration l’inventaire de ces dépendantes avec leurs versions. Cela peut se faire à tout moment avec la commande renv::snapshot() Cette commande crée le fichier renv.lock qui va accompagner le code source dans la forge et l’archive.

partager un environnement virtuel ?

Un environnement virtuel permet deux choses :

composer un document décrivant la liste des packages nécessaires pour l’exécution du code source et de leurs dépendances directes. Ce fichier de configuration est le renv.lock pour Renv, requirements.txt pour Python

conserver les binaires des librairies mentionnées dans ce document.

Lorsqu’on partage le code source, on va seulement partager le fichier de configuration (requirements.txt ou renv.lock), mais pas les binaires des paquets utilisés, car cela prendra trop de place dans l’espace de stockage (par exemple git)

Par conséquent, pour éviter de surcharger le repository, on va ranger les dossiers qui contiennent les binaires dans le fichier .gitignore ; dans un répertoire git, le fichier .gitignore fait l’inventaire de tous les fichiers qui ne doivent pas être pushés c’est à dire envoyés vers la forge distante. Pour Renv c’est automatiquement fait. Pour virtualenv, comme on l’a vu il ne faut partager que le requirements.txt pas l’environnement virtuel en soi.

reproduire l’environnement

Plus tard si on souhaite reproduire l’environnement de travail et repartir avec les mêmes dépendances dans les mêmes versions qui sont appelées par le code source, ou bien si on veut reproduire des environnements réalisés par des collègues, on pourra le faire à partir des fichiers de configuration requirements.txt pour Python ou renv.lock pour R qui accompagnent le code source dans l’archive ou dans la forge.

python

Créer un environnement virtuel. y charger le code source et le fichiers requirements.txt , puis passer la commande suivante pour charger les dépendances inscrites dans ce fichier :

pip -r install requirements.txt

R

Créer un projet. Installer Renv. Passer la commande renv::init() pour initier le dépôt Renv. Charger le code source et le renv.lock récupérés sur la forge ou dans l’archive. Passer la commande suivante : renv::restore() Cela chargera et installera toutes les dépendances listées dans le renv.lock dans les versions qui y sont définies.

Conda

Conda offre la possibilité de créer des environnements virtuels qui sont multilingues, c’est à dire qui ne dépendent pas seulement d’un langage comme Python ou comme R.

Limites des environnements virtuels

pas de prise en compte des dépendances système

la commande pip freeze ne permet de capturer que les librairies Python, pas les dépendances propres au système qui permet à ces dépendances de fonctionner. Si ces dernières manquent sur le système sur lequel on essaie d’exécuter à nouveau le code, le code ne s’éxécutera pas. Il est assez aisé de capturer les librairies Python dans un fichier requirements.txt, c’est beaucoup plus compliqué de capturer de la même manière toutes les dépendances utiles au système d’exploitation pour l’exécution de ce code.

Le code source doit être interprété ou compilé de telle sorte à obtenir des fichiers binaires que l’ordinateur pourra prendre en compte. Le code source est fait pour les humains, mais un ordinateur ne peut exécuter que du binaire. Un humain peut très difficilement lire le contenu d’un fichier binaire, sauf à recourir à des outils spécifiques.

Des variations peuvent survenir dans la manière où tel ou tel système d’exploitation va compiler ou interpréter tel ou tel code source. Cette variabilité due aux compilateurs et aux interpréteurs échappe à l’environnement virtuel.

Pour toutes ces raisons, afin de mettre à disposition un environnement computationnel complet,les chercheurs et chercheuses explorent certaines pistes ouvertes par l’ingénieurie du développement logiciel. Ces pistes sont le plus souvent la virtualisation et la conteneurisation, c’est à dire que l’environnement computationnel sera fourni sous la forme d’un conteneur (Docker par exemple) ou bien d’une machine virtuelle.