Configurer virtualenv en utilisant un requirements.txt généré par conda

Question

Je configure un projet python, en utilisant un environnement virtuel Anaconda. Je génère un requirements.txt afin que d'autres personnes puissent facilement configurer leur propre environnement virtuel pour le projet.

Je me demandais cependant, quand d'autres développeurs veulent contribuer au projet, mais veulent utiliser virtualenv au lieu d'Anaconda, peuvent-ils le faire?

J'ai essayé ce qui suit:

• J'ai mis en place un projet vide dans un environnement Anaconda et installé le module aiohttp. Ensuite conda list --export > requirements.txt génère les éléments suivants:

  # This file may be used to create an environment using:
  # $ conda create --name <env> --file <this file>
  # platform: win-64
  aiohttp=2.3.9=py36_0
  async-timeout=2.0.0=py36hc3e01a3_0
  certifi=2018.1.18=py36_0
  chardet=3.0.4=py36h420ce6e_1
  multidict=3.3.2=py36h72bac45_0
  pip=9.0.1=py36h226ae91_4
  python=3.6.4=h6538335_1
  setuptools=38.4.0=py36_0
  vc=14=h0510ff6_3
  vs2015_runtime=14.0.25123=3
  wheel=0.30.0=py36h6c3ec14_1
  wincertstore=0.2=py36h7fe50ca_0
  yarl=0.14.2=py36h27d1bf2_0
  

• J'ai mis en place un projet vide dans un environnement virtualenv et y ai installé le module aiohttp également. pip freeze > requirements.txt génère alors:

  aiohttp==3.0.1
  async-timeout==2.0.0
  attrs==17.4.0
  chardet==3.0.4
  idna==2.6
  idna-ssl==1.0.0
  multidict==4.1.0
  yarl==1.1.0
  

Donc, apparemment, les deux sorties sont différentes, et ma théorie est: une fois que j'ai généré mon requirements.txt avec conda sur mon projet, les autres développeurs ne peuvent pas choisir virtualenv à la place - du moins pas s'ils ne sont pas prêts à installer une longue liste d'exigences en main (ce sera bien plus que le module aiohttp bien sûr).

Une première vue, importer le fichier requirements.txt généré par conda dans un projet sur virtualenv (pip install -r requirements-conda.txt) renvoie cette erreur:

Invalid requirement: 'aiohttp=2.3.9=py36_0'
= is not a valid operator. Did you mean == ?

Ai-je raison de penser que si les développeurs souhaitent le faire, ils devront modifier par programmation la liste des packages au format que virtualenv comprend, ou ils devront importer tous les packages manuellement? Cela signifie-t-il que je leur impose de choisir conda comme environnement virtuel également s'ils veulent se sauver du travail supplémentaire?

Answer 1

Je mets en place un projet python, en utilisant un environnement virtuel Anaconda. Je me demandais cependant, quand d'autres développeurs veulent contribuer au projet, mais veulent utiliser virtualenv au lieu d'Anaconda, peuvent-ils faire ça?

Oui - en fait, c'est le nombre de mes projets qui sont structurés. Pour accomplir ce que vous cherchez, voici un répertoire simple que nous utiliserons comme référence:

.
├── README.md
├── app
│   ├── __init__.py
│   ├── static
│   ├── templates
├── migrations
├── app.py
├── environment.yml
├── requirements.txt

Dans le répertoire du projet ci-dessus, nous avons à la fois environment.yml (pour les utilisateurs de Conda) et requirements.txt (pour pip).

environment.yml

Donc, apparemment, les deux sorties sont différentes, et ma théorie est: une fois que j'ai généré mon requirements.txt avec conda sur mon projet, les autres développeurs ne peuvent pas choisir virtualenv à la place - du moins pas s'ils ne sont pas prêts à installer une longue liste d'exigences en main (ce sera bien plus que le module aiohttp bien sûr).

Pour surmonter cela, nous utilisons deux fichiers d'environnement différents , chacun dans leur propre format permettant aux autres contributeurs de choisir celui qu'ils préfèrent. Si Adam utilise Conda pour gérer ses environnements, alors tout ce dont il a besoin pour créer son Conda à partir du fichier environment.yml:

conda env create -f environment.yml

La première ligne du fichier yml définit le nom du nouvel environnement. C'est ainsi que nous créons le fichier d'environnement au goût Conda. Activez votre environnement (source activate Ou conda activate) Puis:

conda env export > environment.yml

En fait, comme le fichier d'environnement créé par la commande conda env export Gère à la fois les packages pip et conda de l'environnement, nous n'avons même pas besoin d'avoir deux processus distincts pour créer ce fichier. conda env export Exportera tous les packages de votre environnement, quel que soit le canal à partir duquel ils sont installés. Il en aura également un enregistrement dans environment.yml:

name: awesomeflask
channels:
- anaconda
- conda-forge
- defaults
dependencies:
- appnope=0.1.0=py36hf537a9a_0
- backcall=0.1.0=py36_0
- cffi=1.11.5=py36h6174b99_1
- decorator=4.3.0=py36_0
- ...

requirements.txt

Ai-je raison de penser que si les développeurs souhaitent le faire, ils devront modifier par programmation la liste des packages au format que virtualenv comprend, ou ils devront importer tous les packages manuellement? Cela signifie-t-il que je leur impose de choisir conda comme environnement virtuel également s'ils veulent se sauver du travail supplémentaire?

La manière recommandée (et conventionnelle) de _changer au format que pip comprend passe par requirements.txt. Activez votre environnement (source activate Ou conda activate) Puis:

pip freeze > requirements.txt

Dites Eve, l'une des contributrices du projet souhaite créer un environnement virtuel identique à partir de requirements.txt, Elle peut soit:

# using pip
pip install -r requirements.txt

# using Conda
conda create --name <env_name> --file requirements.txt

Une discussion complète dépasse le cadre de cette réponse, mais questions similaires valent la peine d'être lues.

Un exemple de requirements.txt:

alembic==0.9.9
altair==2.2.2
appnope==0.1.0
arrow==0.12.1
asn1crypto==0.24.0
astroid==2.0.2
backcall==0.1.0
...

Conseils: créez toujours requirements.txt

En général, même sur un projet où tous les membres sont des utilisateurs de Conda, je recommande toujours de créer à la fois le environment.yml (Pour les contributeurs) ainsi que le requirements.txt fichier d'environnement . Je recommande également de faire suivre ces deux fichiers d'environnement par le contrôle de version dès le début (idéalement depuis le début). Cela présente de nombreux avantages, notamment le fait qu'il simplifie votre processus de débogage et votre processus de déploiement ultérieurement.

Un exemple spécifique qui me vient à l'esprit est celui d'Azure App Service. Supposons que vous disposez d'une application Django/Flask, et que vous souhaitez déployer l'application sur un serveur Linux à l'aide d'Azure App Service avec le déploiement git activé:

az group create --name myResourceGroup --location "Southeast Asia"
az webapp create --resource-group myResourceGroup --plan myServicePlan

Le service recherchera deux fichiers, l'un étant application.py Et l'autre étant requirements.txt. Vous avez absolument besoin de ces deux fichiers (même s'il s'agit de fichiers vierges) pour que l'automatisation fonctionne. Bien sûr, cela varie en fonction de l'infrastructure/des fournisseurs de cloud, mais je trouve que le fait d'avoir requirements.txt Dans notre projet nous évite généralement beaucoup de problèmes et vaut les frais généraux de configuration initiaux.

Si votre code est sur GitHub, avoir requirements.txt Vous donne également une tranquillité d'esprit supplémentaire en faisant en sorte que sa détection de vulnérabilité détecte n'importe quel problème avant d'alerter votre propriétaire/référent. C'est beaucoup de grande valeur gratuitement, sur le mérite d'avoir ce fichier de dépendance supplémentaire (petit prix à payer).

C'est aussi simple que de s'assurer que chaque fois qu'une nouvelle dépendance est installée, nous exécutons les commandes conda env export Et pip freeze > requirements.txt.