Il y a deux approches différentes avec ce commit :

• CPython est cloné automatiquement,
• C'est l'utilisateur qui doit manuellement installer le reste des dépendances dans l'environnement virtuel.

Que penseriez-vous de tout migrer vers l'automatique ?

IIRC on le faisait à une époque mais ça pose deux-trois soucis :

• Ça nécessite de préjuger de la commande à utiliser pour invoquer Python (python, python3, py)
• Ça peut échouer, typiquement sur Debian et dérivés qui n'a pas venv dans le paquet Python (il l'ont découpé et mis dans le paquet python3-venv).
• C'est compliqué de savoir si les dépendances sont à jour, ou s'il faut relancer le pip install, et c'est pas sympa de relancer le pip install à chaque fois.

Donc on s'est dit qu'on allait juste dire aux gens d'installer les choses avec un message suffisament précis pour tout dire mais suffisament vague pour qu'ils se débrouillent en fonction de leur environnement, préférences, ...

You're missing dependencies please install:
python -m pip install -r requirements.txt -r venv/cpython/Doc/requirements.txt

J'ai même retiré le conseil de le faire dans un venv, les gens sont libres, s'ils veulent utiliser autre chose, ou installer ça dans ~/.local, libre à eux, ça fonctionnera.

Le but de la PR n'est pas tant d'automatiser le clone de Python, mais plutôt d'utiliser notre propre clone et pas le clone de l'utilisateur, qui pourrait l'utiliser pour autre chose (comme, contribuer à Python), et qui pourrait être embêté par les git checkout en detached-head qu'on fait dessus. Ou qui pourrait être géné s'il a un travail en cours sur cpython, de ne pas pouvoir build la doc (le git checkout refusera de se faire si le dossier n'est pas propre).

IIRC on le faisait à une époque mais ça pose deux-trois soucis :

• Ça nécessite de préjuger de la commande à utiliser pour invoquer Python (python, python3, py)
• Ça peut échouer, typiquement sur Debian et dérivés qui n'a pas venv dans le paquet Python (il l'ont découpé et mis dans le paquet python3-venv).
• C'est compliqué de savoir si les dépendances sont à jour, ou s'il faut relancer le pip install, et c'est pas sympa de relancer le pip install à chaque fois.

Houlà, je retire ce que j'ai dit.

Le but de la PR n'est pas tant d'automatiser le clone de Python, mais plutôt d'utiliser notre propre clone et pas le clone de l'utilisateur, qui pourrait l'utiliser pour autre chose (comme, contribuer à Python), et qui pourrait être embêté par les git checkout en detached-head qu'on fait dessus. Ou qui pourrait être géné s'il a un travail en cours sur cpython, de ne pas pouvoir build la doc (le git checkout refusera de se faire si le dossier n'est pas propre).

Oui, c'est sûr, je me demandais juste si on ne pouvait pas harmoniser, mais c'était une mauvaise idée.