Pipenv: Dernière dépendance par défaut marquée comme locale et modifiable

Créé le 1 oct. 2020 · 9Commentaires · Source: pypa/pipenv

Consultez la documentation de diagnostic pour les problèmes courants. J'ai décrit mon flux de travail (peut-être défectueux) dans les étapes à reproduire ci-dessous. Je m'amuse avec ça depuis quelques semaines en me blâmant et j'aimerais que ce soit un bug de moi.

Description du problème

Le dernier package externe répertorié dans la section par défaut de Pipfile.lock n'est pas correctement marqué comme local et modifiable

Résultat attendu

Le dernier paquet externe répertorié est toujours fourni par pypi

Résultat actuel

Mon Pipfile.lock inclut ce diff, ce qui brise CI et les autres utilisateurs pour des raisons évidentes:

             "version": "==1.25.10"
         },
         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },
     "develop": {

Étapes à suivre pour répliquer

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
flake8 = "3.8.3"
pytest = "5.4.3"
pytest-cov = "2.10.0"
termcolor = "1.1.0"

[packages]
mycli = {editable = true, path = "."}

[requires]
python_version = "3.7"

(mycli a un setup.py pour faciliter la création d'un point d'entrée pour le clic python et définit les dépendances non-dev)

Le projet est un utilitaire CLI et nous clonons le référentiel et l'installons via:
PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy

En tant que développeur ajoutant une nouvelle dépendance, je modifie le setup.py et lance:
pipenv lock

Cela génère un fichier Pipfile.lock qui inclut ma nouvelle dépendance, mais aussi une dernière dépendance par défaut malformée (j'ai eu le problème avec plusieurs packages qui se trouvent près de la fin de l'alphabet à cette position, en particulier wrapt et zipp )

Je suis en mesure de contourner le problème et de générer un Pipfile.lock correct en:
rm -rf Pipfile.lock .venv
et
pipenv lock

J'omets délibérément la sortie pipenv --support car l'application sur laquelle je travaille est propriétaire et je m'inquiète de la fuite des détails de notre environnement (ou de notre équipe de sécurité qui me crie dessus: rire :) S'il y a des extraits spécifiques que je peux frotter et fournir, je serais heureux de le faire, je ne voulais tout simplement pas frotter le tout à l'avance.

Merci d'avoir lu et encore une fois, j'espère que je suis juste stupide.
Merci!

Type Vendored Dependencies

Source

gregflynn

👍3

Commentaire le plus utile

Comme @jmehnle et @patelamol l'ont commenté, j'ai rencontré un problème similaire avec certains de mes packages dans ce cas

       "zipp": {
            "editable": true,
            "path": "."
        },

Ma solution était de modifier manuellement le verrou pipfile, qui est dangereux / malsain à la dernière version

"zipp": {
            "hashes": [
                "sha256:43f4fa8d8bb313e65d8323a3952ef8756bf40f9a5c3ea7334be23ee4ec8278b6",
                "sha256:b52f22895f4cfce194bc8172f3819ee8de7540aa6d873535a8668b730b8b411f"
            ],
            "version": "==3.2.0"
        }

Je me demande si une mise à jour pipenv sortira bientôt avec ce correctif

ch3ck le 9 oct. 2020

👍2

Tous les 9 commentaires

@patelamol et moi pouvons reproduire cela avec pipenv 2020.08.13.

jmehnle le 1 oct. 2020

😕1 👍1

J'ai rencontré ce bug dans toutes les dernières versions jusqu'à 2018.11.26 . Donc 2018.11.26 n'a pas ce problème.

patelamol le 2 oct. 2020

👍2

Comme @jmehnle et @patelamol l'ont commenté, j'ai rencontré un problème similaire avec certains de mes packages dans ce cas

       "zipp": {
            "editable": true,
            "path": "."
        },

Ma solution était de modifier manuellement le verrou pipfile, qui est dangereux / malsain à la dernière version

"zipp": {
            "hashes": [
                "sha256:43f4fa8d8bb313e65d8323a3952ef8756bf40f9a5c3ea7334be23ee4ec8278b6",
                "sha256:b52f22895f4cfce194bc8172f3819ee8de7540aa6d873535a8668b730b8b411f"
            ],
            "version": "==3.2.0"
        }

Je me demande si une mise à jour pipenv sortira bientôt avec ce correctif

ch3ck le 9 oct. 2020

👍2

@gregflynn @patelamol Ce problème existe-t-il donc sur la branche principale? Je ne peux pas reproduire avec les étapes données

frostming le 27 oct. 2020

@gregflynn @patelamol Ce problème existe-t-il donc sur la branche principale? Je ne peux pas reproduire avec les étapes données

Sûrement! Je n'ai pas exécuté pipenv à partir de github auparavant et je n'ai pas vu d'instructions dans le README, je serai donc verbeux sur les étapes:

git cloné
pyenv virtualenv 3.7.9 pipenv && pyenv local pipenv && pip install -e .
vérification:
''
$ pipenv --version
pipenv, version 2020.8.13

$ ~/.pyenv/versions/pipenv/bin/pipenv --version 
pipenv, version 2020.8.13.dev0
```

fait un nouveau venv avec 2020.8.13
ajouté stockquotes == 2.0.0 à mon setup.py
couru ~/.pyenv/versions/pipenv/bin/pipenv lock
Pas de dés, voyant l'erreur avec

         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },

@frostming merci pour la suggestion et pour avoir jeté un coup d'œil, heureux de faire plus de tests ou de corriger ce test si je me suis égaré.

gregflynn le 27 oct. 2020

@gregflynn

fait un nouveau venv avec 2020.8.13

Cette étape est-elle critique pour reproduire le bogue? Je crée avec le maître Pipenv et je ne peux pas reproduire. Une image de docker serait d'une grande aide si possible

frostming le 28 oct. 2020

@gregflynn
fait un nouveau venv avec 2020.8.13
Cette étape est-elle critique pour reproduire le bogue? Je crée avec le maître Pipenv et je ne peux pas reproduire. Une image de docker serait d'une grande aide si possible

Bon œil mais j'ai apporté les modifications suivantes et j'ai toujours pu reproduire avec la dernière version principale. Pour l'étape 4, j'ai mis à jour mon script d'installation:

-PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy
+PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 $HOME/.pyenv/versions/pipenv/bin/pipenv install --deploy

et j'ai toujours:

         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },

Heureux d'essayer plus de choses! Merci

gregflynn le 28 oct. 2020

Oh, j'ai réussi à le reproduire! Je n'ai pas remarqué que le facteur critique est VENV_IN_PROJECT.

frostming le 29 oct. 2020

Oh, j'ai réussi à le reproduire! Je n'ai pas remarqué que le facteur critique est VENV_IN_PROJECT.

: lever_hands: bonne nouvelle! désolé j'ai négligé de vous donner un Dockerfile, j'ai manqué cette note lors de ma première lecture

gregflynn le 29 oct. 2020

Cette page vous a été utile?

0 / 5 - 0 notes

Questions connexes

construire des roues avec pipenv?

ipmb · 3Commentaires

L'analyse Pipfile n'est pas entièrement conforme à TOML

AkiraSama · 3Commentaires

pipenv ne parvient pas à se verrouiller sur le premier package installé

jacebrowning · 3Commentaires

Le verrouillage échoue pour les projets Python 2.7 en raison de vistir

hynek · 3Commentaires

pipenv ne respecte pas le virtualenv actuellement activé et crée un nouvel env

ansrivas · 3Commentaires