venv, direnv, prompt bash (et emacs (et LSP))

[mdk]

J’imagine que ce non-problème à déjà été résolu 200 fois, et qu’on en a déjà parlé un peu, parlons de création et d’activation de venv…

Déjà voilà à quoi ça ressemble chez moi :

Au début : pas de logo Python ça signifie que je ne suis pas dans un venv. Ensuite je tape venv pour créer et activer un venv, mon prompt change avec un logo Python et sa version pour m’indiquer qu’il est activé.

(Oui mon laptop s’appelle seraph et oui j’utilise un thème clair pour mon terminal, oui j’utilise bash. Rohh, c’est pas fini de juger les gens !?)

Donc en ce moment côté création/activation/désactivation de venv j’utilise direnv, avec une petite fonction bash de deux lignes pour se souvenir de ce qu’il faut taper :

venv()
{
    printf "VIRTUAL_ENV=.venv\nlayout python3\n" > .envrc
    direnv allow .
}

de cette manière dès que je cd dans un dossier qui contient un venv, pouf il est activé, et dès que j’en sors pouf il est déactivé. Pour créer un venv dans un dossier j’ai juste à taper venv, c’est le “layout python3” de direnv qui s’occupe de la création et de l’activation. le VIRTUAL_ENV=.venv c’est pour dire à layout python3 où mettre le venv.

Ensuite il me faut une indication que mon venv est activé dans mon prompt, car direnv ne le fait pas. À force de voir des élèves utiliser des prompts “kikoo-lol” je me suis demandé quels caractères unicode ils utilisaient pour faire ces “effets”. Bon bah rien de magique c’est juste 🭮 et 🭬, ou des trucs du genre, avec un peu de couleur.

Et donc une petite fonction bash pour décider s’il faut écrire quelque chose et quoi écrire, injecter ça dans PS1 avec un peu de couleurs et un peu d’unicode, une petite fonte ajoutée contenant un logo Python, et le résultat me convient.

Le code (attention, 42 lignes…):

python-prompt

Ça s’imbrique parfaitement dans emacs avec le module envrc qui met à jour les variables d’environnement au niveau de chaque buffers. Et donc ça marche aussi parfaitement avec lsp-mode, en tout cas avec jedi-language-server qui découvre le venv grâce à la variable d’environnement VIRTUAL_ENV :

[z4c]

Hey,

Pas mal le coup du echo VIRTUAL_ENV=... > .envrc pour mettre à jour la var aussi quand tu changes de repertoire.

A peu prêt pareille, j’ai mis la version avant l’indicateur du layout python.

Par contre tu fais comment pour choisir la 3.11.6 dans pyenv avec ton alias venv ?

[mdk]

@z4c

Par contre tu fais comment pour choisir la 3.11.6 dans pyenv avec ton alias venv ?

Je n’utilise pas pyenv, je n’aime pas du tout leur notion de “shims”, de config alambiquée (par dossier, globale, locale, …).

J’utilise :

compile-python

c’est à dire quasiment rien, je compile mes Pythons moi même, j’ai juste une fonction bash qui fait le wget && configure && make && make altinstall pour ne pas avoir à le retaper à chaque fois.

Pour choisir la version de Python via mon alias venv j’ai deux réponses :

Ma première réponse c’est : je ne choisis pas, mon alias venv prend la version Python fournie par ma distrib (Debian testing). Mes Python “alternatifs” ne sont utilisés que par tox, uniquement par tox. Si mon projet ne fonctionne pas avec le Python fourni par Debian testing j’ai un gros souci à me faire

Ma deuxième réponse c’est : si quelqu’un veut utiliser mon alias ET pouvoir choisir la version de Python ça se fait en ajoutant qq octets à la fonction :

venv()
{
    printf "VIRTUAL_ENV=.venv\nlayout python python$1\n" > .envrc
    direnv allow .
}

Au lieu d’utiliser le layout python3 de direnv, on utilise le layout python en lui précisant le Python voulu : python$1. De cette manière sans paramètre il va utiliser python, (vive apt install python-is-python3 sur Debian), et si on veut un Python 3.12 il faudra invoquer venv 3.12, ça lui fera créer un layout python python3.12.

[z4c]

J’avoue direnv avec des layout par répertoire plus pyenv avec des versions de python par répertoire ça fait au mieux doublon au pire casse tête.

En vrai j’ajouterais bien un which python$1 || python-compile $1 a ton alias pour essayer ce que ça donne à la longue.

[mdk]

@z4c

En vrai j’ajouterais bien un which python$1 || python-compile $1 a ton alias pour essayer ce que ça donne à la longue.

J’aime bien l’idée, tu me diras si tu test

[z4c]

Trop swag l’auto-complete du compile-python fantastique le coup du sed je surkiff au top

Par contre il y a pas moyen de savoir si une version précise est bien installé avec la majeur.mineur.correctif.

Ce qui casse un peu l’alias en mode venv 3.10:

Et le rend tres lent quand tu mets avec le patch venv 3.12.1 ça recompile a chaque fois…

[mdk]

En effet le make altinstall crée python3.12 mais pas python3.12.x.

En rajoutant un petit cp ~/.local/bin/python3.12 ~/.local/bin/python3.12.2 a la fin de compile-python ça pourrait marcher je pense, enfin sans hardcoder la version, il faudrait l’extraire du paramètre (exercice laissé au lecteur).

Pas de symlinks, ça serait une horreur à maintenir et tu ne pourrais avoir qu’une majeure à la fois.

Je reste dans le camp “keep it simple” et je ne précise pas la mineure quand je compile, surtout que je ne précise même pas la version quand je crée un venv…

[z4c]

yes. keep it simple. toujours !
je t’ai fait une “demande d’ajout” ( trop drôle les traductions à la Québécoise ) sur ton repo.
Dis moi ce que t’en penses.