Pipenv: Impossible de créer un verrou même si des dépendances sont trouvées.

Le paquet shakedown devrait probablement être Python 3 uniquement. Cependant, je pense que pipenv devrait créer le verrou uniquement pour une version Python spécifique si le Pipefile inclut une version Python requise.

Voici la sortie détaillée du verrou

pipenv --three lock --verbose

Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  dcos-shakedown from git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown

Finding the best candidates:
  found candidate -e git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown (constraint was <any>)

Finding secondary dependencies:

New dependencies found in this round:
  adding [u'click', '', '[]']
  adding [u'dcos-shakedown', '', '[]']
  adding [u'dcoscli', '==0.5.5', '[]']
  adding [u'paramiko', '', '[]']
  adding [u'pytest', '', '[]']
  adding [u'pytest-timeout', '', '[]']
  adding [u'retrying', '', '[]']
  adding [u'scp', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  click
  dcos-shakedown from git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown
  dcoscli==0.5.5
  paramiko
  pytest
  pytest-timeout
  retrying
  scp

Finding the best candidates:
  found candidate click==6.7 (constraint was <any>)
  found candidate -e git+https://github.com/dcos/shakedown.git#egg=dcos-shakedown (constraint was <any>)
  found candidate dcoscli==0.5.5 (constraint was ==0.5.5)
  found candidate paramiko==2.3.1 (constraint was <any>)
  found candidate pytest==3.2.3 (constraint was <any>)
  found candidate pytest-timeout==1.2.0 (constraint was <any>)
  found candidate retrying==1.3.3 (constraint was <any>)
  found candidate scp==0.10.2 (constraint was <any>)

Finding secondary dependencies:
  click==6.7                requires click==6.7
  scp==0.10.2 not in cache, need to check index
  scp==0.10.2               requires paramiko, scp==0.10.2
  pytest-timeout==1.2.0     requires pytest-timeout==1.2.0, pytest>=2.8.0
  dcoscli==0.5.5 not in cache, need to check index
CRITICAL:pip.index:Could not find a version that satisfies the requirement dcoscli==0.5.5 (from versions: 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.2.0, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.10, 0.4.11, 0.4.12, 0.4.13, 0.4.14)
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
No matching distribution found for dcoscli==0.5.5

C'est étrange. Quand j'installe dcsocli avec pipenv --three install dcoscli je vois

Installing dcoscli…
Collecting dcoscli
  Using cached dcoscli-0.5.5-py3-none-any.whl
````

followed by

                      ROUND 1

Contraintes actuelles:
dcos-shakedown de git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli

Trouver les meilleurs candidats:
a trouvé le candidat -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (la contrainte était)
a trouvé le candidat dcoscli == 0.4.14 (la contrainte était)

Recherche de dépendances secondaires:
dcoscli == 0.4.14 nécessite dcos == 0.4.14, dcoscli == 0.4.14, docopt <1.0,> = 0.6, pkginfo == 1.2.1, toml <1.0,> = 0.9, virtualenv <16.0,> = 13,0
''

pourquoi essaie-t-il d'installer 0.4.14 de dcoscli? Surtout quand pipenv --three run dcos --version produit dcoscli.version=0.5.5 .

Ce n'est pas. C'est le processus de verrouillage. Il fait la résolution des dépendances en fonction de ce qu'il sait et de ce que vous avez mis en cache. Essayez pipenv lock - clair

Le 18 octobre 2017, à 6h16, Karsten Jeschkies [email protected] a écrit:

C'est étrange. Quand j'installe dcsocli avec pipenv --three install dcoscli je vois

Installation de dcoscli…
Collecter dcoscli
Utilisation de dcoscli-0.5.5-py3-none-any.whl mis en cache
suivie par

                      ROUND 1

Contraintes actuelles:
dcos-shakedown de git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli

Trouver les meilleurs candidats:
a trouvé le candidat -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (la contrainte était)
a trouvé le candidat dcoscli == 0.4.14 (la contrainte était)

Recherche de dépendances secondaires:
dcoscli == 0.4.14 nécessite dcos == 0.4.14, dcoscli == 0.4.14, docopt <1.0,> = 0.6, pkginfo == 1.2.1, toml <1.0,> = 0.9, virtualenv <16.0,> = 13,0
pourquoi essaie-t-il d'installer 0.4.14 de dcoscli? Surtout quand pipenv --three run dcos --version renvoie dcoscli.version = 0.5.5.

-
Vous recevez ceci parce que vous êtes abonné à ce fil de discussion.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Vous devrez fournir la sortie de pipenv lock —verbose et pipenv —version

Le 18 octobre 2017, à 6h16, Karsten Jeschkies [email protected] a écrit:

C'est étrange. Quand j'installe dcsocli avec pipenv --three install dcoscli je vois

Installation de dcoscli…
Collecter dcoscli
Utilisation de dcoscli-0.5.5-py3-none-any.whl mis en cache
suivie par

                      ROUND 1

Contraintes actuelles:
dcos-shakedown de git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown
dcoscli

Trouver les meilleurs candidats:
a trouvé le candidat -e git + https://github.com/dcos/shakedown.git#egg = dcos-shakedown (la contrainte était)
a trouvé le candidat dcoscli == 0.4.14 (la contrainte était)

Recherche de dépendances secondaires:
dcoscli == 0.4.14 nécessite dcos == 0.4.14, dcoscli == 0.4.14, docopt <1.0,> = 0.6, pkginfo == 1.2.1, toml <1.0,> = 0.9, virtualenv <16.0,> = 13,0
pourquoi essaie-t-il d'installer 0.4.14 de dcoscli? Surtout quand pipenv --three run dcos --version renvoie dcoscli.version = 0.5.5.

-
Vous recevez ceci parce que vous êtes abonné à ce fil de discussion.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

La suppression du cache de verrouillage n'a pas aidé. Voici la sortie complète de pipenv --three lock --verbose

› pipenv --three lock --verbose
Virtualenv already exists!
Removing existing virtualenv…
Warning: PYENV_ROOT is not set. New python paths will probably not be exported properly after installation.
Creating a virtualenv for this project…
Using /Users/kjeschkies/.pyenv/shims/python3 to create virtualenv…
⠋Running virtualenv with interpreter /Users/kjeschkies/.pyenv/shims/python3
Using base prefix '/Users/kjeschkies/.pyenv/versions/3.5.2'
New python executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python3
Also creating executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1
Current constraints:
  dcos-shakedown

Finding the best candidates:
  found candidate dcos-shakedown==1.4.8 (constraint was <any>)

Finding secondary dependencies:
  dcos-shakedown==1.4.8     requires click, dcos-shakedown==1.4.8, dcoscli==0.5.5, paramiko, pytest, pytest-timeout, retrying, scp

New dependencies found in this round:
  adding [u'click', '', '[]']
  adding [u'dcos-shakedown', '==1.4.8', '[]']
  adding [u'dcoscli', '==0.5.5', '[]']
  adding [u'paramiko', '', '[]']
  adding [u'pytest', '', '[]']
  adding [u'pytest-timeout', '', '[]']
  adding [u'retrying', '', '[]']
  adding [u'scp', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  click
  dcos-shakedown==1.4.8
  dcoscli==0.5.5
  paramiko
  pytest
  pytest-timeout
  retrying
  scp

Finding the best candidates:
  found candidate click==6.7 (constraint was <any>)
  found candidate dcos-shakedown==1.4.8 (constraint was ==1.4.8)
  found candidate dcoscli==0.5.5 (constraint was ==0.5.5)
  found candidate paramiko==2.3.1 (constraint was <any>)
  found candidate pytest==3.2.3 (constraint was <any>)
  found candidate pytest-timeout==1.2.0 (constraint was <any>)
  found candidate retrying==1.3.3 (constraint was <any>)
  found candidate scp==0.10.2 (constraint was <any>)

Finding secondary dependencies:
  pytest-timeout==1.2.0 not in cache, need to check index
  pytest-timeout==1.2.0     requires pytest-timeout==1.2.0, pytest>=2.8.0
  paramiko==2.3.1           requires bcrypt>=3.1.3, cryptography>=1.5, paramiko==2.3.1, pyasn1>=0.1.7, pynacl>=1.0.1
  click==6.7 not in cache, need to check index
  click==6.7                requires click==6.7
  pytest==3.2.3             requires py>=1.4.33, pytest==3.2.3, setuptools
  dcos-shakedown==1.4.8     requires click, dcos-shakedown==1.4.8, dcoscli==0.5.5, paramiko, pytest, pytest-timeout, retrying, scp
  retrying==1.3.3           requires retrying==1.3.3, six>=1.7.0
  dcoscli==0.5.5 not in cache, need to check index
CRITICAL:pip.index:Could not find a version that satisfies the requirement dcoscli==0.5.5 (from versions: 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.2.0, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.4.0, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.10, 0.4.11, 0.4.12, 0.4.13, 0.4.14)
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
No matching distribution found for dcoscli==0.5.5

Pour info à chaque fois que vous passez - trois, vous dites à pipenv de détruire votre virtualenv existant, je ne sais pas si c'était prévu, mais juste pour info. Je vais examiner cela un peu plus, mais en un coup d'œil, puisque pyenv est installé, vous devez également définir la variable d'environnement PYENV_ROOT par le message d'erreur.

@techalchemy , merci. Je ne savais pas que --three créerait un nouvel env à chaque fois. Je pensais que cela indiquerait simplement à pipenv de n'utiliser que Python 3. J'ai défini PYENV_ROOT une fois, mais pipenv a ensuite créé un virtuelenv avec Python 3.6 au lieu de 3.5 comme défini dans mon pyenv local.

Je pense toujours que le problème est que pipenv essaie de créer une fermeture pour Python 2 et que le shakedown ne se limite pas à Python 3.

Jeter dans mon observation sur le comportement de résolution des dépendances:
Il semble vraiment que l'exécutable Python 2 ou pip2 soit utilisé pour la résolution des dépendances ici.
J'ai le sentiment d'avoir vu des problèmes similaires ces derniers temps, mais je n'ai pas eu le temps de l'examiner.

En supposant ici sur l'environnement ici, je dirais que pipenv été installé globalement (ce qui est ok), et que le python global ou racine est Python 2. @jeschkies Pouvez-vous confirmer si c'est vrai? Remarque, je ne parle pas de la version python du virtualenv créé par pipenv , je parle de l'exécutable python utilisé pour exécuter pipenv .
J'ai également noté que vous semblez utiliser pyenv , je ne suis pas sûr qu'il y ait un effet secondaire ici sur l'exécutable python utilisé par pipenv lui-même ..

Je ne suis pas (encore) un expert sur la façon dont pipenv détermine quelle version de python / pip utiliser pour lui-même, mais s'il choisit aveuglément le python racine de l'environnement dans lequel il est installé pour lui-même, alors nous savons pourquoi nous obtenons des résultats python 2 ici.

Merci pour les pointeurs @vphilippon. J'ai arraché mon ancienne version pyenv et installé la dernière version et Python 3.5.2. J'ai ensuite mis à jour pip vers la version 9.0.1 en dehors de virtualenv. J'ai également corrigé shakedown pour exiger une version spécifique de Python et utilisé des dépendances git. Voir
• https://github.com/jeschkies/shakedown/blob/master/setup.py
• https://github.com/mesosphere/marathon/blob/karsten/use-pipenv/Pipfile

Je me demande comment fonctionne le verrou car il ne mentionne pas le hachage de validation pour autant que je sache. De plus, le verrou indique que la version dcos cli est 0.4.14 mais pipenv run dcos --version génère 0.5.5.

Dans l'ensemble, je me demande comment pipenv gère différentes versions de Python et à quoi doit-on s'attendre de pipenv à cet égard.

Hm le verrou ne fonctionne pas pour les dépendances:

system in marathon/ on karsten/use-pipenv
› pipenv --rm
Removing virtualenv (/Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI)…

system in marathon/ on karsten/use-pipenv
› pipenv install
Creating a virtualenv for this project…
Using /Users/kjeschkies/.pyenv/versions/3.5.2/bin/python3.5m to create virtualenv…
⠋Running virtualenv with interpreter /Users/kjeschkies/.pyenv/versions/3.5.2/bin/python3.5m
Using base prefix '/Users/kjeschkies/.pyenv/versions/3.5.2'
New python executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python3.5m
Also creating executable in /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/kjeschkies/.local/share/virtualenvs/marathon-ldTRsJsI
Installing dependencies from Pipfile.lock (0d5d00)…
Ignoring ipaddress: markers 'python_version < "3"' don't match your environment
Ignoring enum34: markers 'python_version < "3"' don't match your environment
Ignoring futures: markers 'python_version == "2.7"' don't match your environment
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 34/34 — 00:00:08
To activate this project's virtualenv, run the following:
 $ pipenv shell

system in marathon/ on karsten/use-pipenv
› pipenv run dcos --version
dcoscli.version=0.4.14
dcos.version=1.9.4
dcos.commit=f843772e2740889cc4bba263db44f1403e670037
dcos.bootstrap-id=79f6d6e1c406bffd3fab28b36815220575ae5995

Donc, en gros, installer avec pipenv install -e git+https://github.com/jeschkies/shakedown#egg=dcos-shakedown créant un Pipefile.lock qui n'est pas tout à fait précis.

Eh bien, la commande que vous avez exécutée vient de réutiliser le fichier de verrouillage que vous aviez déjà présent, je pense que pipenv doit d'abord savoir quelle version de python il est censé utiliser si vous avez besoin d'une version différente de la version par défaut pour votre cas d'utilisation

En regardant cela, la valeur par défaut, le venv semble utiliser Python 3.5.2 et évalue les marqueurs en tant que tels. Cela ressemble à un pas en avant.

@jeschkies Je supprimerais le Pipfile.lock et lancerais pipenv lock --clear pour faire un verrouillage fersh. Si le problème de python racine n'est plus en cause, cela devrait le faire.

Je suis d'accord avec @vphilippon, mais si vous avez d'autres problèmes, je vous demanderais si vous pouvez fournir vos Pipfile et Pipfile.lock afin que nous puissions vous aider dans le processus de dépannage.

J'ai commencé à zéro sans Pipfile.lock , puis j'ai utilisé le fichier de verrouillage pour recréer l'environnement. Je vais essayer une fois de plus un rapport.

Bien. J'ai reproduit le problème dans un dossier vierge. Vous voyez toutes les commandes de la sortie dans cet essentiel .

Voici ce que j'essaye de faire et ce qui se passe:

1. Installez shakedown depuis git pour Python 3.5 avec pipenv --three -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown
2. dcos-cli, une dépendance de shakedown est l'installation avec la version 0.5.5. C'est comme prévu.
3. Supprimez virtualenv avec pipenv --rm .
4. Créez une nouvelle virtualenv avec pipenv --three install .
5. dcos-cli 0.4.14 est installé. Ce n'est pas prévu.

D'accord, mais j'ai toujours besoin que vous incluiez votre pipfile.lock pour aider à résoudre les problèmes. Pouvez-vous également fournir la sortie de pipenv lock —verbose après avoir vu les informations de version incorrectes

Voici la sortie de pipenv lock --verbose et le Pipfile.lock généré

Le Pipfile.lock comprend

"dcos": {
    "hashes": [
                "sha256:3d48d0773b5dd5e82ddb9cfa946f17755789e8c2ff53ecc75b32194b41248611"
            ],
    "version": "==0.4.14"
}

mais le pipenv run dcos --version donne dcoscli.version=0.5.5 .

Très bien, cette sortie verbeuse donnée est cohérente et correspond au contenu du Pipfile.lock .
Mais la version installée rapportée (à partir de dcos --version ) ne correspond pas.

J'ai essayé les étapes et je n'ai pas pu reproduire. Je reçois:

"dcos": {
    "hashes": [
        "sha256:01d722e13296bd38c2b391ffbd5bc111fa7b5ec09bb058651713bce62a2d45a7"
    ],
    "version": "==0.5.5"
},
"dcos-shakedown": {
    "editable": true,
    "git": "https://github.com/jeschkies/shakedown.git",
    "ref": "012841a38a59d00043c15a66400501811715ab86"
},
"dcoscli": {
    "hashes": [
        "sha256:47b442a2823ab3b27cd520f5c3762ab0e630eca473a273e111619bd5c1a16ea6"
    ],
    "version": "==0.5.5"
},

et, à partir de pipenv run dcos --version

dcoscli.version=0.5.5
dcos.version=N/A
dcos.commit=N/A
dcos.bootstrap-id=N/A

à la fois lors de la première installation et lors de la réinstallation à partir du Pipfile.lock .

@jeschkies Dans les commandes de l'essentiel, je n'ai vu aucun pipenv lock --clear (notez le --clear ). L'avez-vous exécuté comme je l'ai suggéré auparavant? Sinon, veuillez le faire, car cela pourrait toujours être un problème avec le cache de dépendances. (Et il n'y a aucun mal à le refaire pour être sûr à 100%.)

Sinon, si nous sommes sûrs à 100% que le cache des dépendances a été effacé, veuillez donner la sortie de pipenv run pip freeze .

@vphilippon utilisez-vous pyenv ? Je soupçonne que c'est le problème ici. Je ne peux pas l'obtenir pour verrouiller dcos-cli 0.5.5 avec ce qui suit:

• mkdir pipenv-test && cd pipenv-test
• pyenv local 3.5.2
• pipenv --three install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown

Le Pipfile.lock aura le 0.4.14. Qu'est-ce que j'oublie ici? Pipenv récupère-t-il la version de Python ou le mauvais package dcos-cli?

@jeschkies Non, je n'utilise pas pyenv . C'était la prochaine chose que j'allais vérifier, après m'être assuré qu'il ne s'agissait pas d'un problème de cache de dépendances. Je voulais aussi jeter un œil à la liste complète des versions de paquet installées, c'est pourquoi j'ai demandé la sortie de pipenv run pip freeze .

Nous aurons besoin de quelqu'un pour essayer d'utiliser pyenv et essayer de reproduire, bien que si tout votre environnement python est maintenant sur Py 3+, cela ne devrait pas être un problème provoquant le calcul des dépendances Py 2.

Je ne pense pas que pipenv respecte le paramètre pyenv local, ce qui vous posera potentiellement des problèmes. Quand j'ai essayé d'exécuter simplement pipenv install... mon système a tenté de revenir à python 2.7.

L'exécution de la commande en tant que pipenv --python=3.5.2 install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown a très bien fonctionné (et est le moyen recommandé de spécifier des versions de python à pipenv au lieu d'espérer qu'il récupère un fichier local):

        "dcos": {
            "hashes": [
                "sha256:01d722e13296bd38c2b391ffbd5bc111fa7b5ec09bb058651713bce62a2d45a7"
            ],
            "version": "==0.5.5"
        },
        "dcos-shakedown": {
            "editable": true,
            "git": "https://github.com/jeschkies/shakedown.git",
            "ref": "012841a38a59d00043c15a66400501811715ab86"
        },
        "dcoscli": {
            "hashes": [
                "sha256:47b442a2823ab3b27cd520f5c3762ab0e630eca473a273e111619bd5c1a16ea6"
            ],
            "version": "==0.5.5"
        },

Pour info, il s'agit d'un problème lié à la façon dont pipenv résout les chemins python pyenv, car il ne connaît pas les paramètres locaux pyenv, il utilisera sa propre estimation de l'interpréteur python à utiliser dans virtualenv par rapport à la résolution des dépendances. Ceux-ci finiront par être différents car l'un sera résolu par les cales pyenv et l'autre ne le sera pas.

@techalchemy est-ce un bug dans pipenv ou pyenv ou les deux ???

Voici la sortie de pipenv run pip freeze après avoir exécuté pipenv --python=3.5.2 install -e git+https://github.com/jeschkies/shakedown.git#egg=dcos-shakedown . Voici le contenu du Pipfile.lock

       "dcos": {
            "hashes": [
                "sha256:3d48d0773b5dd5e82ddb9cfa946f17755789e8c2ff53ecc75b32194b41248611"
            ],
            "version": "==0.4.14"
        },
        "dcos-shakedown": {
            "editable": true,
            "git": "https://github.com/jeschkies/shakedown.git",
            "ref": "012841a38a59d00043c15a66400501811715ab86"
        },
        "dcoscli": {
            "hashes": [
                "sha256:1d7506df5e32fc96566169896fb42ba80aba4687d1c65eb2b52b320b5cfad0ca"
            ],
            "version": "==0.4.14"
        },

C'est tellement étrange. Même avec pyenv global 3.5.2 cela ne fonctionne pas.

@jeschkies essayez pipenv lock —clear per @vphillipon ci-dessus maintenant que vous avez explicitement dit à pipenv d'utiliser 3.5.2 et voyez si vous vous retrouvez avec les bonnes résolutions

@erinxocon ce n'est un bogue que si vous pensez que pipenv doit respecter les paramètres pyenv locaux en général. Ce que je veux dire, c'est que si vous définissez pyenv local 3.5.2 puis exécutez pipenv install je pense que cela fonctionne correctement. Cependant, les indicateurs d'aide —three et —two recherchent le chemin séparément pour la dernière version installée, quelle que soit celle que vous avez configurée avec pyenv. La question est donc de savoir si pipenv doit plutôt respecter vos sélections pyenv si elles s'appliquent. Cela ressemble à un cas particulier, surtout lorsque vous pouvez simplement être explicite lorsque vous ne voulez pas la dernière version.

@techalchemy même un pipenv lock --clear ne fonctionnait pas. Je pense que c'est vraiment pipenv ignorant ma configuration pyenv quoi qu'il arrive. Quel est le chemin de recherche de pipenv pour Python avec l'option --three dans macOS?

@jeschkies Il regarde simplement votre variable $ PATH pour effectuer une recherche.

@techalchemy Je suis déchiré. Un peu semble être un problème d'environnement utilisateur, hors du champ d'application de pipenv. Cependant, c'était à l'origine notre pensée lors de l'utilisation de pew pour la gestion de virtualenv, ce qui a causé plus de problèmes en raison de shells qui ne sont pas configurés correctement, donc bien qu'il ne s'agisse pas d'un problème de pipenv, nous avons changé pour éviter les problèmes.

@erinxocon hm, comment auriez-vous différentes versions de Python sans pyenv? Dois-je simplement les installer et les avoir tous sur $PATH ? Cela ne semble pas juste. Je comprends que pipenv ne devrait pas être trop intelligent à ce sujet. Cependant, certains documents aideraient probablement ici.

@jeschkies normal python est mis sur le chemin, et si vous installez 6 versions oui, tout va sur votre chemin. Pyenv est une fonction d'assistance mais n'est certainement pas nécessaire et pipenv ne lit pas les fichiers de configuration. Il recherche simplement sur votre chemin ce vers quoi «python» pointe à moins que vous ne spécifiiez une version ou un exécutable spécifique. Les cales Pyenv sont un peu désordonnées, ce qui explique pourquoi nous ne les utilisons pas.

--three et --two recherchez simplement le chemin de python3 ou python2 dans votre chemin. Pour le moment, python2 ne peut être nommé que python et python3 est python3 . Vous pouvez avoir toutes les versions de python dans votre chemin, elles seront simplement adressées en utilisant une syntaxe plus spécifique. python26 , python27 , python34

HM OK. Existe-t-il donc un autre moyen de gérer les versions de Python qui fonctionnent mieux avec pipenv?

@jeschkies plus gentil? J'utilise personnellement pyenv avec PIPENV_DEFAULT_PYTHON_VERSION SET TO 3.6.3 . Avec pyenv installé (ou n'importe quelle configuration vraiment), vous pouvez simplement passer —python=3.6.3 ou —python=2.7.14 . C'est la chose avec deviner (c'est-à-dire avec —three et —two ) - ce n'est pas explicite. Si vous voulez une version spécifique, vous devrez la spécifier

J'ai le même problème en essayant d'installer Django==2.0b1 . Il ne propose qu'une roue Python 3 (identique à dcoscli ).

J'ai installé Pipenv dans le monde entier via Homebrew et j'utilise pyenv pour gérer mes versions de Python. J'ai également spécifié python_full_version = "3.6.3" dans mon Pipfile (avec l'option avant-première).

Cela échoue lorsque j'exécute pipenv install via le Pipenv global, mais si j'installe Pipenv (via Pip) dans une version Python 3, cela réussit. Je suppose que cela signifie que Pipenv n'utilise pas la version spécifiée dans Pipfile pour rechercher la version de dépendance? J'obtiens la même erreur lors de l'utilisation de pip install dans Python 2.7.10.

J'ai essayé d'utiliser la variable d'environnement PIPENV_DEFAULT_PYTHON_VERSION , mais cela n'a pas fonctionné non plus.

Salut @jamieconnolly Je pense que cela pourrait avoir quelque chose à voir avec les shims que pyenv met en place pour rendre plusieurs environnements disponibles. Je ne peux pas en être sûr car je n'utilise pas pyenv.

@jamieconnolly Je suppose que c'est lié au même bogue pour lequel nous avons des points de contact à divers endroits concernant, comme vous l'avez mentionné, la supercherie de résolution de dépendances. Une question cependant - est-ce que pipenv install installe avec succès la version spécifiée dans le premier cas, mais échoue à l'étape de résolution et vous conseille d'utiliser --skip-lock ? Ou échoue-t-il à installer en premier lieu?

@jamieconnolly , merci pour l'indice. Je vais essayer d'utiliser une installation pipenv via pip de la configuration pyenv locale.

@techalchemy , je devrais être plus précis. Il semble que pipenv ne récupère pas la bonne version de Python de pyenv lorsqu'il génère le Pipfile.lock. Comme tu l'as dit

La question est donc de savoir si pipenv doit plutôt respecter vos sélections pyenv si elles s'appliquent.

Étant donné que la réponse n'est pas nécessairement oui, je me demande comment gérer différentes versions de Python pour que pipenv choisisse la bonne lorsqu'il génère le fichier de verrouillage.

Je vais aussi essayer --python=3.6.3 .

@jeschkies ce que je voulais dire par là, c'est qu'il ne respecte pas ce que vous définissez avec pyenv shell ou pyenv local ou autre. Il doit respecter les pythons qui sont sur votre chemin, et potentiellement si pyenv est configuré correctement, il respectera tout ce qui est défini avec pyenv global puisque c'est ainsi que le shim pour python sera résolu (si vous ne spécifiez pas de version )

Ok, mais je me demande pourquoi la version pyenv local Python n'est pas trouvée lorsque le fichier de verrouillage est généré. C'est soit la configuration de pyenv, soit un problème avec pipenv. Je ne suis pas sûr que ce soit la configuration car pipenv n'a aucun problème à installer le bon package et la version Python dans pipenv shell python --version est également correcte. Alors pourquoi pipenv lock ne prend-il pas la bonne version?

@jeschkies parce que si vous ne spécifiez pas de version, pipenv run et pipenv shell seront par défaut en python système (que pyenv résoudra via des shims si vous utilisez pyenv local pour ce que vous définissez ). La résolution se produit en utilisant le résolveur pip-tools et n'invoque jamais directement python, donc les shims pyenv sont essentiellement contournés pour la résolution de version et pipenv regarde simplement votre PATH et PYENV_ROOT pour tous les pythons disponibles. C'est pourquoi pyenv local n'a aucun impact sur le fichier de verrouillage.

@techalchemy , ah, ok, je pense avoir une idée de la différence maintenant. Donc pipenv install et pipenv shell invoquent Python directement et c'est pourquoi je termine avec les versions correctes là-bas?

@jeschkies c'est généralement vrai, même si je pense que pipenv shell dépendra de l'utilisation ou non de la variable d'environnement PIPENV_SHELL_FANCY / sont sur Windows

Je rencontre le même problème avec Django==2.0rc1 . Vraiment pas grand chose à ajouter à part ce que @jamieconnolly a dit, mais voici quelques données, si vous le souhaitez:

Pipfile
`` `nom = Pipfile
[[la source]]
url = " https://pypi.python.org/simple "
verify_ssl = true
name = "pypi"

[dev-packages]

[paquets]

"psycopg2" = "*"
django = "== 2.0rc1"

[pipenv]
allow_prereleases = true

➜ metada git: (maître) ✗ pip3 freeze
certifi == 2017.11.5
chardet == 3.0.4
Django == 2.0rc1
flocon8 == 3.5.0
idna == 2.6
mccabe == 0.6.1
pew == 1.1.0
pycodestyle == 2.3.1
pyflakes == 1.6.0
pytz == 2017.3
demandes == 2.18.4
urllib3 == 1.22
virtualenv == 15.1.0
virtualenv-clone == 0.2.6

When I try to lock, even with `--pre`, I get this:

➜ metada git: (maître) ✗ pipenv lock --pre
Verrouillage des dépendances [dev-packages]…
Verrouillage des dépendances [packages]…
CRITIQUE: pip.index : Impossible de trouver une version qui satisfait à l'exigence django == 2.0rc1 (à partir des versions: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4. 2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.6, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7, 1.6.8, 1.6.9, 1.6.10, 1.6.11, 1.7, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7, 1.7.8, 1.7.9, 1.7.10, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.8.6, 1.8.7, 1.8.8, 1.8.9, 1.8.10, 1.8.11, 1.8.12, 1.8.13, 1.8.14, 1.8.15, 1.8. 16, 1.8.17, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9. 7, 1.9.8, 1.9.9, 1.9.10, 1.9.11, 1.9.12, 1.9.13, 1.10a1, 1.10b1, 1.10rc1, 1.10, 1.10.1, 1 .10.2, 1.10.3, 1.10.4, 1.10.5, 1.10.6, 1.10.7, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7)
Avertissement: vos dépendances n'ont pas pu être résolues. Vous avez probablement une incompatibilité dans vos sous-dépendances.
Vous pouvez utiliser $ pipenv install --skip-lock pour contourner ce mécanisme, puis exécuter $ pipenv graph pour inspecter la situation.

So when I do that, and run the graph:

➜ metada git: (maître) ✗ graphe pipenv
Django == 2.0rc1

• pytz [requis: Tout, installé: 2017.3]
  psycopg2 == 2.7.3.2

Just can't create a lock file if I specify the version like that.

If I drop the `==2.0rc1` in `Pipfile` and allow pre-relerases (which I already did), it'll go back to a 1.17 something like that in the lock file, which isn't what I want.

And here's a another output:

➜ metada git: (master) ✗ pipenv run pip freeze
Django == 2.0rc1
pytz == 2017.3
''

Désolé de spammer tout le monde, mais j'ai également trouvé une solution de contournement à mon problème. Au départ, j'avais installé la tuyauterie via brew mais j'ai décidé de passer à l'installation via pip , ou plutôt pip3 via pip3 install --user pipenv .

Cette version de pipenv a pu verrouiller correctement mon Django==2.0rc1 . Je ne sais pas si le n ° 965 est vraiment lié à cela, mais j'ai également vu ce problème pendant que Googlin ', alors j'ai pensé le mentionner. Fondamentalement, la façon dont une installation pipenv semble faire une différence quant à savoir si elle prend les bonnes roues python lors de l'installation / verrouillage.

Il me semble avoir contourné un problème similaire en supprimant l'installation de homebrew pipenv et en utilisant un pip3 install pipenv standard. Je pense que mes messages d'erreur concernent les dépendances python 2 que https://github.com/Homebrew/homebrew-core/blob/master/Formula/pipenv.rb nécessitent, je m'attends à une installation native de python2 plutôt que de profiter de python 3 si disponible. J'essaierai d'envoyer un message d'erreur lorsque j'aurai le temps de me reproduire.

cela est probablement dû aux contraintes de setup.py, nous ne pouvons rien y faire

par exemple, installez pipenv avec python3

Homebrew pipenv utilisera bientôt python3 par défaut pour éviter ces problèmes.