Utiliser un vrai pom.xml, requirements.txt, package.json ou go.mod dans une tâche de code

Un élève qui apprend avec un vrai requirements.txt, pom.xml ou package.json apprend ce qu’il retrouvera dans chaque emploi et chaque projet libre. Une tâche de code déclare donc ses paquets exactement ainsi : dans le fichier que lisent les outils du langage, en haut de l’arborescence de la tâche, sans rien d’autre à remplir.

Le même fichier fonctionne sur l’ordinateur d’un élève : un projet copié hors de la plateforme, ou chargé depuis Git, continue de fonctionner sans que personne ne réécrive ses paquets dans un format à nous.

Quel fichier, pour quel langage

Python lit requirements.txt ou pyproject.toml, et un notebook lit requirements.txt. Java lit pom.xml. Go lit go.mod. JavaScript et TypeScript sur Node lisent package.json. Le fichier se trouve en haut de l’arborescence, marqué « Paquets », et une nouvelle tâche s’ouvre avec un petit exemple à remplacer.

Bash, SQL, C, C++, C#, Haskell, OCaml, R, Ruby, PHP, Rust, Kotlin et Prolog n’ont pas de fichier de paquets : leurs exécutions n’ont pas de réseau qu’un gestionnaire de paquets pourrait atteindre, et ce dont ils ont besoin est déjà installé.

  1. Ouvrez la tâche dans son éditeur. Le fichier de paquets est en haut de l’arborescence, marqué « Paquets ».
  2. Indiquez les paquets. Écrivez-les comme sur votre propre ordinateur, chacun avec sa version exacte. Un intervalle comme >=2.0 ou ^4.18 est refusé, car une version qui change d’une exécution à l’autre n’est pas une version sur laquelle on peut noter.
  3. Ou apportez le fichier que vous avez déjà. Importez-le en haut de l’arborescence, ou créez-y un fichier de ce nom, et il devient la liste de paquets de la tâche.
  4. Cliquez sur « Exécuter ». Les paquets sont installés avant le démarrage du programme. La première exécution prend plus de temps ; les suivantes réutilisent ce qui a été récupéré.

Comment les paquets sont installés

Les paquets sont récupérés dans un conteneur à part et remis à l’exécution en lecture seule, et l’exécution elle-même n’a pas de réseau. Le programme d’un élève ne peut donc rien télécharger pendant qu’il tourne, et une tâche qui déclare les mêmes paquets qu’une autre réutilise ce qui a déjà été récupéré.

Les paquets de chaque langage viennent d’une liste approuvée de paquets largement utilisés, reconnus comme leur écosystème les nomme : les paquets Python et npm par leur nom, Java par le groupe de l’éditeur et Go par le chemin du module. Un paquet absent de la liste est refusé avant toute exécution, et le message le nomme. Si votre cours a besoin d’un paquet qui manque, demandez-le depuis la page Support.

Un fichier de paquets peut faire jusqu’à 64 Ko, comme tout autre fichier de la tâche. Les fichiers de verrouillage comme package-lock.json ou poetry.lock ne sont pas lus : ce sont les versions exactes du fichier de paquets qui sont installées.

Java et Maven

Un pom.xml est lu comme Maven le lit pour ses dépendances : propriétés, gestion des dépendances, pom parent et imports de BOM, et portées, un paquet de portée test comme JUnit n’étant là que pour les tests. Les paquets viennent de Maven Central. Un fichier de construction Gradle n’est pas lu ; utilisez un pom.xml.

Une tâche Java créée avant la prise en charge de pom.xml garde son ancien dependencies.xml, qui fonctionne toujours. Pour passer à un pom, collez-y un pom.xml complet ou renommez-le pom.xml.

Python, Node et Go

Une tâche Python a un seul fichier de paquets à la fois : pour passer de requirements.txt à pyproject.toml, renommez le fichier. Un pyproject.toml est lu pour les dépendances de sa table [project] ou de la table de dépendances de Poetry.

Un package.json est lu pour ses dependencies, et aussi pour ses devDependencies quand les tests s’exécutent, puisque c’est là qu’un projet JavaScript garde ce que seuls ses tests importent. Les scripts d’installation ne sont jamais exécutés.

Un go.mod est lu pour ses dépendances, et pour une directive replace qui renvoie un module vers un dossier du projet lui-même : une tâche peut donc être un module Go avec ses propres paquets.

Qui peut modifier la liste

Les élèves voient toujours le fichier de paquets, car le lire fait partie de la compréhension du projet. Pouvoir le modifier est un paramètre de la tâche : si c’est permis, un élève ajoute un paquet à sa copie comme sur son propre ordinateur, et l’exécution suivante l’installe.

Questions fréquentes

Les élèves peuvent-ils installer des paquets eux-mêmes ?
Sur toute tâche qui a un fichier de paquets, si la tâche les autorise à le modifier. Ils ajoutent le paquet au fichier comme sur leur propre ordinateur, et l’exécution suivante l’installe.
Un programme peut-il télécharger des paquets pendant son exécution ?
Non. L’exécution n’a pas de réseau ; les paquets sont récupérés avant, dans un conteneur à part, depuis la liste approuvée.
Gradle est-il pris en charge ?
Non. Les tâches Java lisent un pom.xml.
Pourquoi chaque version doit-elle être exacte ?
Pour que chaque élève de la classe, et la notation, s’exécutent avec les mêmes paquets. Un intervalle installerait la version la plus récente du jour.