web-dev-qa-db-fra.com

pip is error, TypeError: __call __ () prend exactement 2 arguments (1 donné)

système

  • centos 7.2
  • Python 2.7.5

installer

J'installe webhook

pip install webhook
### but hava error,then
yum install python-devel -y
## go on,pip doesn't workding
pip

erreur

Entrez la commande contient pip.Then

[root@location src]# pip
Traceback (most recent call last):
File "/usr/bin/pip", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 72, in <module>
import packaging.requirements
File "/usr/lib/python2.7/site-packages/packaging/requirements.py", line 59, in <module>
MARKER_EXPR = originalTextFor(MARKER_EXPR())("marker")
TypeError: __call__() takes exactly 2 arguments (1 given)

Donc qu'est ce que je devrais faire?!

python-2.7pip
28
hysg

METTRE À JOUR:

S'il vous plaît voir le solution plus bas dans ce fil par Pedro Werneck au lieu de celui-ci. C'est la bonne façon de résoudre le problème.

Préface: je ne le recommande pas!

Cela semble fonctionner, mais je n'ai aucune idée de ce que pourraient être les conséquences. C'est la programmation culte du cargo à son meilleur! Je ne fais que l'ajouter ici au cas où cela pourrait aider quelqu'un dans une impasse.

J'ai apporté des modifications au fichier requirements.py où l'erreur s'est produite. Pour @hysg, ce serait ce fichier:

/usr/lib/python2.7/site-packages/packaging/requirements.py

Sur moi sur OS X, c'est ici:

/Library/Python/2.7/site-packages/packaging/requirements.py

J'ai modifié la ligne incriminée en supprimant les parenthèses pour l'appel à MARKER_EXPR, comme illustré ci-dessous:

#MARKER_EXPR = originalTextFor(MARKER_EXPR())("marker")
MARKER_EXPR = originalTextFor(MARKER_EXPR)("marker")

Et cela a fonctionné.

Encore une fois, soyez prudent! Je ne sais pas ce que je fais et cela pourrait potentiellement causer plus de tort que de bien.

28
RobotNerd

J'ai eu le même problème sur une nouvelle virtualenv et apparemment, il s'agit d'un conflit entre les exigences de version pour packaging, pip et pyparsing avec le nouveau setuptools. Ce qui a fonctionné pour moi, c’était de déterminer l’ancien.

pip install setuptools==33.1.1

Mettre à jour:

Comme une autre réponse l’a souligné, pip a déjà corrigé le bogue. Vous devez donc essayer de le mettre à niveau au lieu d’utiliser la solution ci-dessus.

python -m pip install --upgrade --force pip
70
Pedro Werneck

c'est du travail bien ：

python -m pip install --upgrade --force pip 
pip install setuptools==33.1.1
23
Timi

C'est ce qui a fonctionné pour moi:

pip install setuptools==33.1.1

Il a abaissé la valeur de setuptools de 35.0.1 à 33.1.1 et la version 1.5.7 installée!

11
rtindru

J'ai appliqué le correctif

pip installer setuptools == 33.1.1

et il a résolu le problème pour OSX 10.10.5 (Yosemite)

10
Scott Frazier

Utilisez la commande suivante pour mettre à niveau pip, qui corrige le bogue:

python -m pip install --upgrade --force pip

Cela a fonctionné pour moi (centos 7, python 2.7). 

Pour plus de détails: GitHub

10
LI Bing

J'ai rencontré le même problème sur un nouveau virtualenv essayant d'installer. J'exécute python 2.7.11 et trouve les deux commandes ci-dessous qui résolvent le problème de versioning avec setuptools:

Cela oblige une mise à niveau pip, qui corrige le bogue, mais ne réinstalle pas les outils de configuration, donc je fonctionnais toujours sur la version 35.0.1 de setuptools

python -m pip install --upgrade --force pip

Cela définit setuptools sur une version plus ancienne.

pip install setuptools==33.1.1

Après cela, j'ai installé avec succès mes exigences.

2
Justin

En fait, le problème est que OS/system, qui signifie root, et non Sudo, est le propriétaire du paquet pip2. Mais après avoir exécuté cette commande:

Sudo apt-get remove python-pip

Ça a marché comme sur des roulettes.
Notant, bien sur que j’ai une distribution debian.

Et puis j'ai utilisé ce que Pedro a suggéré:

Sudo pip install setuptools==33.1.1
1
Steven

Aucune des autres réponses de désinstallation/réinstallation/force n'a fonctionné pour moi, mais sous OS X 10.10.5 avec le système Python 2.7.10, j'ai pu effectuer les tâches suivantes:

pip uninstall packaging pip
easy_install pip # this installed pip 1.4.1
pip install --upgrade pip # and this upgraded to the current pip

et j’ai alors pu import pkg_resources sans problème.

Devrait vraiment apprendre à arrêter de jouer avec le système Python…

1
Nicholas Riley

Cela a fonctionné pour moi aussi (centos 7, python 2.7). 

python -m pip install --upgrade --force pip 
pip install setuptools==33.1.1
0
loyo