Pipenv: 2018.11.26: pipenv émet des erreurs pythons lors de la création d'un virtualenv

Il semble que /usr/local/bin/pythonz n'est plus un chemin valide.

Hmm. Aurait-il jamais dû l'être? Je n'ai jamais utilisé directement pythonz. Je pensais que c'était juste une dépendance pipenv qu'il gérait lorsque j'ai installé pipenv.

Pour commencer, je viens de désinstaller et de réinstaller pipenv 2018.11.26 et j'ai toujours le problème.

Pouvez-vous fournir la sortie de pipenv --support ? Et pour confirmer, non ça n'aurait pas dû être

Oh nvm vient de voir votre message. Je veux juste confirmer qu'il n'y a pas de version escroc de pipenv sur votre chemin quelque part. Pouvez-vous vérifier which pipenv et python -m pipenv --version

$ which pipenv
/usr/local/bin/pipenv

python -m pipenv --version renvoyé No module named pipenv parce que Python 2 et Python 3 sont installés via Homebrew, et python exécute Python 2.7. Selon une recommandation précédente ici, j'ai installé pipenv sous Python 3. J'ai donc remplacé python3 et j'ai obtenu:

$ python3 -m pipenv --version
pipenv, version 2018.11.26

Merci!

Ah ok. Et oui, le bug a du sens. Je vais juste le taguer en amont et m'assurer qu'il est corrigé

Un mot sur quand un correctif sera publié pour cela? J'ai ce problème, il m'empêche d'installer les exigences de pipenv. J'ai essayé la solution de contournement de @commandtab sans une telle chance.

Je ne peux pas pipenv travailler du tout avec la version actuelle.

$ which pipenv
/Users/josh/.pyenv/shims/pipenv

$ python -m pipenv --version
pipenv, version 2018.11.26

J'ai essayé d'installer avec python3.7 depuis homebrew, et le même problème.

Il semble qu'il n'y a pas d'urgence ici, ou que ce n'est pas un gros problème. Est-ce que je manque quelque chose ou est-ce que pipenv est complètement cassé avec la version actuelle?

La version actuelle me semble sûrement arrosée. Une autre solution de contournement temporaire que j'ai vue dans un problème précédent était de passer spécifiquement un chemin python comme ceci:

pipenv --three --python=`which python3`

Je fais ça avec succès pour le moment: grimaçant:

Cette solution de contournement ne fonctionnait pas pour moi. J'ai dû passer à 2018.10.13 , puis utiliser la solution de contournement sur ce fil :

pipenv install -d --python=$HOME/.pyenv/versions/3.7.1/bin/python

Pour autant que je sache, pipenv est complètement cassé depuis octobre.

@techalchemy Un mot sur un correctif de balise en amont? La création de pipenv virtualenv nécessite toujours des solutions de contournement pour l'appel.

Merci ❤️

C'était un peu difficile avec tous les autres correctifs qui devaient être intégrés, mais je pense que CI passera maintenant et cela sera corrigé avec # 3330 - désolé pour le problème

Ah ok. Et oui, le bug a du sens. Je vais juste le taguer en amont et m'assurer qu'il est corrigé

Le problème persiste, aucune idée de la date à laquelle ce correctif sera publié.

Même problème ici.

Peut confirmer que la solution de contournement de @ command-tab fonctionne toujours.

Cela se produit définitivement avec l'homebrew pipenv et python ... un peu surpris qu'il n'y ait pas de test pour le couvrir vu depuis combien de temps ce problème existe ...

Je peux également confirmer que ce problème se produit toujours, malgré la résolution de ce problème GitHub.

Les responsables ont-ils besoin de créer un nouveau problème?

Même problème avec Ubuntu 18 LTS installé dans le sous-système Windows pour Linux.

La solution de contournement fonctionne pour moi.

@techalchemy ce problème semble toujours exister. Pouvez-vous le rouvrir ou indiquer clairement que vous souhaitez qu'un nouveau numéro soit créé?

Merci.

Même problème avec Ubuntu 18 LTS installé dans le sous-système Windows pour Linux.

pareil ici

@techalchemy s'il vous plaît jeter un œil à nouveau

Même problème ici sur macOs Mojave et python 3.7

Moi aussi:

• Catalina
• Python 3.7.

Tout fonctionne bien une fois que j'ai commenté cette ligne dans mon Pipfile:

[requires]

#python_version = "3.7.4"

Moi aussi:

• Catalina
• Python 3.7.

Tout fonctionne bien une fois que j'ai commenté cette ligne dans mon Pipfile:

[requires]

#python_version = "3.7.4"

ahhhh cela a fonctionné pour moi, merci!

@JarredStanford @edsu
Cela a fonctionné pour moi aussi sur WSL dans VSCode (je n'ai pas essayé un shell extérieur car cela fonctionnait bien pour un projet différent).

@ command-tab
L'ajout de "--python = which python3 " a également fonctionné. Je n'ai pas essayé d'ajouter "--three" et cela ne semble pas nécessaire pour mon cas d'utilisation / ma version.

Après avoir obtenu les deux solutions de contournement et j'ai pu le faire fonctionner, je les ai supprimées et j'ai essayé une troisième fois de m'assurer que l'environnement causait toujours un problème (narrateur: c'était le cas).

@techalchemy
Je pense que ce n'est peut-être pas "entièrement résolu" dans 3330? Cela pourrait être un problème tangentiel causant les mêmes symptômes. Dans mon cas, j'utilise WSL et je me demande si 'python3' et 'python3.exe' étant tous deux dans mon chemin WSL semble suspect.

Pensez-vous qu'il vaut mieux que j'ouvre un nouveau problème, souhaitez-vous que j'exécute des diagnostics supplémentaires, ou autre chose?

J'utilise wsl2 avec arclinux (manjaro)
Il semble que pipenv appelle le python dans les fenêtres d'environnement hôte pour l'installer
nous devons donc définir où trouver le python avec:
pipenv --python=<PATH_TO_PYTHON>
ou
pipenv --python=which python3

travaille pour moi.

Peut confirmer que cela se produit sous WSL avec Ubuntu 18.04 LTS. Il semble que pipenv cherche un interpréteur python plutôt que d'utiliser celui sous lequel il est exécuté, et ce faisant, il parcourt PATH dans l'ordre inverse. J'ai plusieurs environnements python installés, et chaque fois que j'en supprime manuellement un de PATH, pipenv en trouve un différent et se plaint de celui-ci à la place.

Je vois le même problème sous WSL avec Ubuntu 18.04 LTS. pipenv install --python $(which python3) fonctionne mais quand je fais par la suite pipenv shell , il ne trouve pas les dépendances qu'il aurait dû télécharger.

Je suis également concerné, en utilisant WSL 1 et Ubuntu 18.04. Solution --python $(which python) contournement

La raison de la dernière partie de l'exception, c'est-à-dire ce bit:

  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/utils.py", line 68, in get_python_version
    combine_stderr=False, write_to_stdout=False)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 314, in run
    write_to_stdout=True
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 162, in _create_subprocess
    sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))
TypeError: write() takes exactly one argument (3 given)

... est qu'il y a un bogue dans l'appel pour imprimer une erreur lors de la gestion de la première exception. Ce bogue semble avoir déjà été corrigé dans master en janvier 2019 - https://github.com/pypa/pipenv/commit/574fe7308d9ac81d64da954722f35c9eee0dd467#diff -a59595db75020aeb9f688d6a0b4818e6L162. Mais comme la dernière version de pipenv est 2018.11.26, j'imagine que la plupart n'ont pas de version fixe.

On peut le patcher manuellement. Ouvrez /usr/local/lib/<your-python-version>/site-packages/pipenv/vendor/vistir/misc.py , accédez à la ligne 162 et modifiez ceci:

sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))

... pour ça:

sys.stderr.write(f"Error {exc} while executing command " + " ".join(cmd._parts))

Vous obtiendrez maintenant un rapport d'exception plus précis. Dans mon cas, le problème est lié au fait que pipenv basé sur WSL Linux détecte les installations Python basées sur Windows et a des difficultés à les exécuter, ce qui est assez évident:

Error [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe' while executing command /mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe -c import sys; print(['Traceback (most recent call last):\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/contextmanagers.py", line 150, in spinner\n    yield _spinner\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 314, in run\n    write_to_stdout=True\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 160, in _create_subprocess\n    combine_stderr=combine_stderr)\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 134, in _spawn_subprocess\n    return subprocess.Popen(cmd, **options)\n', '  File "/usr/lib/python3.6/subprocess.py", line 729, in __init__\n    restore_signals, start_new_session)\n', '  File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child\n    raise child_exception_type(errno_num, err_msg, err_filename)\n', "OSError: [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe'\n"]

Pour les utilisateurs WSL, je pense que le problème peut être résolu en garantissant que toutes les exigences de votre version Python dans Pipfile correspondent _exactement_ à une installation Python basée sur Linux, par exemple

[requires]
python_version = "3.6.8"  # Make sure this exactly matches an installed version, or remove it.

J'espère que cela t'aides.

Je ne sais pas à quel point cela aide, mais supprimer le Pipfile, exécuter pipenv lock , puis remettre le contenu de l'ancien Pipfile et exécuter pipenv install fonctionne pour moi en permanence.