Question pas importante du tout. Encore que…
Quelle est la meilleur solution pour créer les virtualenv ?
venv a la racine de chaque projet.~/virtualenv/.J’ai du mail à cerner quels peuvent être les inconvénients / avantages de ces différentes options. Vos retours d’expérience m’intéressent.
Quand je ne suis pas dans mon environnement préféré, je claque un “venv” à la racine du projet, comme ça c’est tout de suite visible qu’il y a un venv associé.
Sinon sur mon ordinateur perso, j’utilise pyenv pour gérer mes versions de Python et mes environnements virtuels. C’est très pratique et le boilerplate peut être adapté en fonction des circonstances mais je sais que beaucoup n’aiment pas.
J’ai tendance a pencher pour la première option, je trouve facile de retrouver la venv même plusieurs mois / années plus tard. Ne pas oublier de le mettre dans le .gitignore / .dockerignore / autreoutilignore pour éviter des énormes pertes de temps lorsqu’un outil essaye de reformatter, analyser ou indexer tout ton venv
Le problème de venv c’est qu’il symlink le Python que tu as utilisé au moment de sa création, et si ton venv est un peu vieux et que tu as mis à jour ton interpréteur depuis, tu l’as dans l’os, c’est pourquoi c’est pas mal de versionner l’interpréteur aussi. 
TL;DR: J’ai essayé les deux, c’est pareil pour moi.
J’ai pendant longtemps utilisé des ~/.venvs/{projectname}, selon mon git log en 2017 j’utilisais :
workon()
{
local VENVS="$HOME/.venvs"
deactivate >/dev/null 2>/dev/null
if [ -z "$1" -o z"$1" = z"." ]
then
local VENV_NAME="$(basename "$PWD")"
else
local VENV_NAME="$1"
fi
[ -d "$VENVS/$VENV_NAME" ] || mkdir -p "$VENVS/$VENV_NAME"
[ -f "$VENVS/$VENV_NAME/bin/activate" ] || python3 -m venv "$VENVS/$VENV_NAME"
. "$VENVS/$VENV_NAME/bin/activate"
}
_workon()
{
COMPREPLY=( $( compgen -W '$( command ls "$HOME/.venvs" )' -- "${COMP_WORDS[COMP_CWORD]}") )
}
complete -F _workon workon
Avantages :
rm -fr ~/.venvs dès que tu veux récupérer de la place sur ton disque.Inconvénients :
Puis 2 ans plus tard, en 2019, j’ai essayé de mettres les venvs dans les dossier de projet plutôt que dans mon home, et dans une envie de simplification j’ai tout remplacé par :
alias venv='deactivate 2>/dev/null; [ -d .venv ] || python3 -m venv --prompt "$(basename "$PWD")" .venv; source .venv/bin/activate'
rm -fr ~/.venvs/, mais je survis à coup de rm -fr ~/clones/*/.venv.Entre les deux je n’ai vu quasiment aucune différence, je pense que ce qui pèse dans la balance c’est ce qui fait plaisir à ton IDE et tes goûts personnels.
D’ailleurs pyenv est bien pris en compte par PyCharm depuis un ou deux ans, ce qui est fort appréciable !
Je suis passé à ~/.venv/* pour les exclure facilement de mes sauvegardes. La faute a DejaDup pas très souple sur la configuration des exclusions.
Depuis je suis passé a Borgmatic qui est bien plus configurable pour le perso, mais je ne pense pas déplacer mes venvs pour le moment.
Mes alias:
alias vact='source ~/.venvs/$(pwd | cut -d"/" -f5)/bin/activate'
alias vc10='~/pylocal/bin/python3.10 -m venv --clear --copies ~/.venvs/$(pwd | cut -d "/" -f5)'
alias vc='python3 -m venv --clear --copies ~/.venvs/$(pwd | cut -d "/" -f5)'
alias vdestroy='VENV_PATH="${HOME}/.venvs/$(pwd | cut -d"/" -f5)/" && echo ${VENV_PATH} && rm -rfI ${VENV_PATH}'
alias gps='for proj in $(find ~/git -mindepth 1 -maxdepth 1 -type d -printf "%p\n");do RES=$(git -C ${proj} status -s) && [[ -n ${RES} ]] && echo "\n# ${proj#${HOME}/git/}:\n${RES}";done'
alias gpu='for proj in $(find ~/git -mindepth 1 -maxdepth 1 -type d -printf "%p\n");do git -C ${proj} fetch --prune --quiet || echo "ERROR fetching git repo: ${proj#${HOME}/git/}";done'
Mouais, le problème de le renseigner dans ces fichiers s’ils sont partagés avec d’autres (le .gitignore) par exemple c’est que chacun devrait alors y mettre le nom de son propre répertoire où il place le venv et ça devient vite le bazar.
Mais pour git il y a aussi .git/info/exclude qui a le mérite de ne pas être partagé.
Choix 2 , ici c’est ~/Projects avec chacun d’eux dans un venv.
Je n’ai pas trouvé d’inconvénient ^^
Merci à tous pour vos réponses ainsi que pour les exemples d’alias…
Je vais donc, pour le moment garder mes petites habitudes avec un venv dans la HOME de chaque ‘projet’. Je vais juste changer par défaut pour l’appeler .venv plutôt que venv. Et puis grâce à vous, je suis en train de me rajouter des alias dans mon .bash_aliases et faire un peu de tri entre les .gitignore et le .git/info/exclude 
[EDIT : pour le dernier point, je me demande si je ne vais pas plutôt uiliser ~/.gitingore. Si j’ai bien compris, va s’appliquer à tous les repository locaux …
Selon man gitignore (je n’ai pas essayé) tu ne peux pas utiliser un ~/.gitignore, git ne cherchera que jusqu’a la racine du repo, pas plus haut.
Tu peux cependant configurer core.excludesFile dans ton ~/.gitconfig
C’est ce que je suis en train de regarder puis tester. (j’aurai du le faire avant mon EDIT 
)
Brett Cannon vient de publier un article à ce sujet sur son blog : Classifying Python virtual environment workflows.
TL;DR:
When I did a poll via Mastodon to figure out why people used a central directory approach, the majority of people did it that way because their tool happened to work that way or it was just habit (53%). The next biggest group kept their environments in a central directory for environment reuse (24%).
Je réponds un peu tard, mais voici mon fonctionnement.
Utilisant souvent les mêmes composants et ayant parfois d’un environnement juste pour quelques tests, j’ai repris la commande bash de @mdk pour en faire une commande “globale” : le venv est au niveau de mon répertoire ~/projets
Mais comme certains projets ont des besoins spécifiques (ou des versions précises), j’ai également repris la commande en mode "par projet : ~/projets/projet_1/
Par contre, j’utilise “venv” comme nom, pour ne pas avoir ce répertoire caché, je trouve ça plus simple à gérer.
Pour reprendre ce qu’ont dit @dancergraham et @entwanne : je vais voir à l’ajouter côté git config, mais ça me semble indispensable de le mettre dans le gitignore du projet pour éviter qu’un autre participant ne pousse le sien par erreur (donc .venv et venv au moins)
Perso j’utilise pew qui je trouve me simplifie bien la vie. J’ai toujours du mal avec les fichiers/répertoires qui trainent dans les projets. C’est une source de soucis avec les gitignore. Dans les projets sur lesquels je travail c’est a l’appréciation du dev, par contre les gitignore doivent rester clean pour tout le monde.