Dans cette partie, nous avons jusqu'ici appelé nos environnements virtuels de la même manière pour les deux projets : env . Cela peut prêter à confusion, pourtant c'est un cas d' usage répandu ainsi qu'une convention assez largement utilisée par les professionnels. Naturellement, vous pouvez donner à vos environnements virtuels le nom que vous voulez.

Une question bien naturelle se pose alors : « Pourquoi ne donnons-nous pas à nos environnements virtuels un nom spécifique ? ». Les raisons sont les suivantes :

Si vous basculez très vite entre un grand nombre de projets ou de répertoires différents, il est pratique de pouvoir toujours activer votre environnement virtuel avec la commande source env/bin/activate plutôt que d'utiliser ls pour répertorier les fichiers ou les répertoires à la racine de votre projet afin de retrouver (ou de vous rappeler) le nom de l'environnement virtuel, puis d'exécuter source <env name>/bin/activate pour l'activer.

En général, le répertoire de l'environnement virtuel n'est pas inclus dans le dépôt Git d'un projet. De ce fait, le répertoire est ajouté au fichier .gitignore. Par exemple, configurons demo-app en tant que dépôt Git en exécutant git init.

Si vous exécutez maintenant une commande git status, vous constaterez que demo.py est un fichier non suivi et que l'environnement virtuel (le répertoire env ) est également non suivi.

Nous ne voulons pas ajouter env au dépôt Git, donc nous allons plutôt l'ajouter à un fichier .gitignore. Créez un fichier appelé .gitignore contenant les éléments suivants :

.gitignore

env/

Maintenant, si vous exécutez à nouveau git status, vous ne devez voir que le fichier demo.py, et le .gitignore non suivi qui vient d'être créé : nous avons réussi à ignorer le répertoire env.

On peut maintenant ajouter ces deux fichiers à l'index et créer un premier commit.

Maintenant, imaginez un scénario dans lequel 10 à 15 développeurs travaillent sur un projet individuel. Si chacun donne à son environnement virtuel un nom unique et l'ajoute à .gitignore , cela deviendra vite ingérable !

Une autre question souvent posée est “Pourquoi ne pas appeler notre environnement virtuel par le nom du projet auquel il est associé ?”. La réponse est très simple : cela crée un conflit de noms de répertoires, ce qui est, a nouveau, souvent source de confusion.

• Créez 3 projets différents. Chaque projet doit contenir le même script. Le script doit utiliser la bibliothèque requests pour envoyer une requête GET à https://www.example.com.
• Créez un environnement virtuel dans chaque répertoire de projet, mais en veillant à ce que chaque environnement virtuel ait un nom différent.
• Si vous êtes à l'aise avec git, initialisez chaque répertoire comme dépôt Git, et ajoutez chaque environnement virtuel au fichier .gitignore.
• Entraînez-vous à passer rapidement d'un environnement virtuel à l'autre, et à exécuter chaque projet.
• Répétez les tâches ci-dessus, mais cette fois, donnez à tous vos environnements virtuels le nom env.

Choisissez parmi les conventions de nommage celle que vous trouvez la plus facile !

• Comprendre les avantages et les inconvénients des méthodes particulières de nommage des environnements virtuels.
• Établir votre préférence sur la façon de nommer vos environnements virtuels.

Maintenant que vous avez appris les bonnes pratiques pour nommer les environnements virtuels, demandons-nous comment installer automatiquement les paquets qui doivent se trouver dans chaque environnement virtuel.

◁ Précédent | ⌂ Retour au sommaire | Suivant ▷