Concepts

xbee-install et Dev Containers : proches par l'objectif, différents par l'usage

Comprendre ce que xbee-install partage avec les Dev Containers et pourquoi son unité d'usage reste la commande plutôt que le conteneur.

À première vue, xbee-install évoque naturellement les Dev Containers. Les deux approches cherchent à rendre un environnement de développement reproductible : le projet déclare les outils dont il dépend, leurs versions et leur environnement d’exécution, au lieu de demander à chaque développeur de les installer manuellement sur son poste.

La ressemblance est réelle, mais l’expérience proposée n’est pas la même. Un Dev Container place le développeur et généralement son éditeur dans un environnement de développement conteneurisé. xbee-install présente plutôt les outils du conteneur comme des commandes du projet, utilisables depuis le shell hôte.

Cette différence déplace l’unité d’usage : avec un Dev Container, c’est le conteneur ; avec xbee-install, c’est la commande.

Le besoin commun : supprimer le « fonctionne sur ma machine »

Un projet Maven peut exiger Maven 3.8.8, un JDK 17, certaines variables d’environnement et des outils système particuliers. Une documentation qui demande à chaque développeur d’installer cette combinaison ne garantit pas que tous obtiendront le même résultat.

Dev Containers et Xbee répondent tous deux à ce problème en décrivant l’environnement dans le dépôt :

les versions des outils sont explicites ;
le système de base est maîtrisé ;
l’installation peut être reconstruite ;
l’environnement est partagé par l’équipe et par la CI ;
le poste du développeur reste peu dépendant des outils du projet.

Dans les deux cas, l’environnement devient une donnée versionnée avec le code plutôt qu’une configuration implicite de la machine.

Le modèle xbee-install

Un fichier xbee-install.yaml associe un projet à un ou plusieurs packs. Chaque pack peut installer ses dépendances, définir ses variables d’environnement et exposer des commandes.

schema-version: "1.0"

pack:
  origin: ../packs/maven
  var:
    jdk.xbee.version: "17"

Si le pack Maven expose mvn, la commande est disponible dans le contexte du projet :

xbee mvn clean install

xbee enter ouvre en plus un shell interactif dans lequel le préfixe xbee devient inutile :

xbee enter
mvn clean install

Ce shell reste un shell du host. Xbee y ajoute temporairement des wrappers pour les commandes déclarées par les packs. Lorsqu’un wrapper est appelé, Xbee démarre le conteneur adapté, transmet les arguments et l’environnement, monte le projet, exécute la commande, puis restitue son code de sortie.

Le développeur utilise donc mvn, node ou un autre outil comme s’il était installé localement, alors que son exécutable et ses dépendances résident dans une image gérée par Xbee.

Le modèle Dev Container

Un Dev Container décrit un environnement de développement complet. Le dépôt est ouvert dans ce conteneur et le terminal intégré, les extensions de l’éditeur, les processus de développement et les outils s’exécutent généralement à l’intérieur de celui-ci.

Le conteneur devient ainsi le poste de travail du projet. Ce modèle convient très bien quand toute la session doit partager le même système : éditeur, débogueur, shell, services auxiliaires et outils de compilation.

Avec xbee-install, le poste de travail reste celui du développeur. Seules les commandes déclarées franchissent la frontière du conteneur.

Deux frontières différentes

Question	Dev Container	`xbee-install`
Où se trouve le shell principal ?	Dans le conteneur	Sur le host
Quelle est l’unité d’usage ?	L’environnement complet	La commande exposée par un pack
L’éditeur doit-il entrer dans le conteneur ?	Généralement oui	Non
Comment les outils sont-ils invoqués ?	Directement dans le conteneur	Comme commandes locales relayées par Xbee
Comment l’environnement est-il composé ?	Image, Features et configuration du projet	Packs, dépendances et variables surchargeables
Quel est le périmètre naturel ?	Une session de développement	Un projet et ses outils

Cette comparaison ne signifie pas qu’une approche remplace systématiquement l’autre. Elles choisissent simplement une frontière différente entre le host et l’environnement reproductible.

Ce que les packs ajoutent au modèle

Dans Xbee, Maven n’est pas seulement une étape inscrite dans la définition d’un projet. Il peut être publié comme un pack autonome, dépendre d’un pack JDK et être réutilisé par plusieurs projets :

projet A ─┐
          ├── pack Maven ── pack JDK 17
projet B ─┘

Un projet peut surcharger la version du JDK sans copier la recette d’installation :

pack:
  origin: ../packs/maven
  var:
    jdk.xbee.version: "21"

La composition et la surcharge font du pack une unité de distribution indépendante du projet consommateur. C’est l’une des différences conceptuelles les plus importantes avec une configuration centrée sur un unique environnement de développement.

Ce que xbee-install ne cherche pas à reproduire

xbee-install ne doit pas être présenté comme un Dev Container doté d’une autre syntaxe. Dans son fonctionnement actuel, il ne décrit notamment pas :

la configuration de l’éditeur ;
les extensions à installer dans l’éditeur ;
tout le cycle de vie d’un espace de travail interactif ;
une session permanente dans laquelle chaque processus du développeur s’exécute.

Inversement, un Dev Container n’a pas nécessairement pour objectif de transformer chaque outil conteneurisé en commande transparente du shell hôte ni de distribuer cet outil comme un pack composable entre plusieurs projets.

Quand choisir l’un ou l’autre ?

Un Dev Container est naturel lorsque l’équipe veut standardiser le poste de travail complet : même éditeur, mêmes extensions, même terminal et éventuellement plusieurs services associés.

xbee-install est particulièrement adapté lorsque l’objectif est de fournir une chaîne d’outils reproductible tout en conservant l’expérience habituelle du poste :

mvn clean install
npm test
terraform plan

Le développeur n’a pas à gérer lui-même l’image, les montages, l’utilisateur interne ou le cycle de vie des conteneurs associés à ces commandes.

Les deux modèles peuvent aussi coexister. Un Dev Container peut fournir le poste de travail général tandis que des packs Xbee définissent et partagent certaines chaînes d’outils. Cette combinaison n’est utile que si elle conserve une responsabilité claire pour chacun des deux niveaux ; dupliquer la même installation dans les deux systèmes annulerait une partie du bénéfice de reproductibilité.

Une formulation simple

Pour présenter xbee-install à une personne qui connaît déjà les Dev Containers :

xbee-install apporte la reproductibilité d’un environnement conteneurisé, mais expose ses outils comme des commandes du projet au lieu de faire du conteneur le poste de travail du développeur.

La comparaison avec les Dev Containers est donc un bon point d’entrée. La distinction à retenir est que xbee-install abstrait d’abord l’installation et l’exécution des outils, tandis qu’un Dev Container abstrait d’abord l’environnement de développement complet.