Pipenv: Die letzte Standardabhängigkeit wird als lokal und bearbeitbar markiert

Erstellt am 1. Okt. 2020  ·  9Kommentare  ·  Quelle: pypa/pipenv

Die Diagnosedokumentation wurde auf häufig auftretende Probleme überprüft. Ich habe meinen (möglicherweise fehlerhaften) Workflow in den folgenden Schritten beschrieben. Ich habe ein paar Wochen damit herumgespielt und mich selbst beschuldigt, und würde es lieben, wenn dies ein Ich-Käfer wäre.

Fehlerbeschreibung

Das letzte externe Paket, das im Standardabschnitt von Pipfile.lock aufgeführt ist, wird fälschlicherweise als lokal und bearbeitbar markiert

Erwartetes Ergebnis

Das letzte aufgeführte externe Paket wird weiterhin von pypi bereitgestellt

Tatsächliche Ergebnis

In meinem Pipfile.lock ist dieses Diff enthalten, wodurch CI und andere Benutzer aus offensichtlichen Gründen beschädigt werden:

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

Zu replizierende Schritte

[[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 hat eine setup.py, um das Erstellen eines Einstiegspunkts für Python-Klicks zu erleichtern und Nicht-Entwickler-Abhängigkeiten zu definieren.)

Das Projekt ist ein CLI-Dienstprogramm und wir klonen das Repository und installieren es über:
PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy

Als Entwickler, der eine neue Abhängigkeit hinzufügt, bearbeite ich die setup.py und führe Folgendes aus:
pipenv lock

Dadurch wird eine Pipfile.lock-Datei generiert, die meine neue Abhängigkeit, aber auch eine fehlerhafte letzte Standardabhängigkeit enthält (ich hatte das Problem mit mehreren Paketen, die sich an dieser Position am Ende des Alphabets befinden, insbesondere wrapt und zipp )

Ich kann das Problem umgehen und ein korrektes Pipfile.lock generieren, indem ich:
rm -rf Pipfile.lock .venv
und
pipenv lock

Ich lasse die Ausgabe von pipenv --support absichtlich weg, da die Anwendung, an der ich arbeite, proprietär ist und ich mir Sorgen mache, dass Details unserer Umgebung verloren gehen (oder unser Sicherheitsteam mich anschreit: lacht :). Wenn es bestimmte Schnipsel gibt, die ich schrubben und bereitstellen kann, würde ich mich freuen, wollte das Ganze einfach nicht im Voraus schrubben.

Vielen Dank fürs Lesen und noch einmal, ich hoffe, ich bin nur dumm.
Vielen Dank!

Type Vendored Dependencies
Quelle
picture gregflynn
👍3

Hilfreichster Kommentar

Wie @jmehnle und @patelamol kommentierten, ist in diesem Fall bei einigen meiner Pakete ein ähnliches Problem 

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

Meine Lösung bestand darin, die Pipfile-Sperre manuell zu bearbeiten, was für die neueste Version unsicher / ungesund ist

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

Ich frage mich, ob es bald ein Pipenv-Update mit diesem Bugfix gibt

picture ch3ck am 9. Okt. 2020
👍2

Alle 9 Kommentare

@patelamol und ich können dies mit pipenv 2020.08.13 reproduzieren.

jmehnle picture jmehnle am 1. Okt. 2020
😕1 👍1

Ich habe diesen Fehler in der neuesten Version bis 2018.11.26 erlebt. 2018.11.26 hat dieses Problem also nicht.

patelamol picture patelamol am 2. Okt. 2020
👍2

Wie @jmehnle und @patelamol kommentierten, ist in diesem Fall bei einigen meiner Pakete ein ähnliches Problem 

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

Meine Lösung bestand darin, die Pipfile-Sperre manuell zu bearbeiten, was für die neueste Version unsicher / ungesund ist

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

Ich frage mich, ob es bald ein Pipenv-Update mit diesem Bugfix gibt

ch3ck picture ch3ck am 9. Okt. 2020
👍2

@gregflynn @patelamol Gibt es dieses Problem also in der Hauptniederlassung? Ich kann mit den angegebenen Schritten nicht reproduzieren

frostming picture frostming am 27. Okt. 2020

@gregflynn @patelamol Gibt es dieses Problem also in der Hauptniederlassung? Ich kann mit den angegebenen Schritten nicht reproduzieren

Sicherlich! Ich habe pipenv noch nie von github ausgeführt und keine Anweisungen in der README-Datei gesehen, daher werde ich die Schritte ausführlich beschreiben:

  1. git geklont
  2. pyenv virtualenv 3.7.9 pipenv && pyenv local pipenv && pip install -e .
  3. Überprüfung:
    `` `
    $ pipenv --version
    pipenv, Version 2020.8.13
$ ~/.pyenv/versions/pipenv/bin/pipenv --version 
pipenv, version 2020.8.13.dev0
```

  1. machte mit 2020.8.13 ein frisches venv
  2. stockquotes == 2.0.0 zu meiner setup.py hinzugefügt
  3. lief ~/.pyenv/versions/pipenv/bin/pipenv lock
  4. Keine Würfel, sehe den Fehler mit
         "wrapt": {
-            "hashes": [
-                "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
-            ],
-            "version": "==1.12.1"
+            "editable": true,
+            "path": "."
         }
     },

@frostming Vielen Dank für den Vorschlag und einen Blick darauf, gerne weitere Tests durchzuführen oder diesen Test zu korrigieren, wenn ich vom Weg abgekommen bin.

gregflynn picture gregflynn am 27. Okt. 2020

@gregflynn

  1. machte mit 2020.8.13 ein frisches venv

Ist dieser Schritt wichtig, um den Fehler zu reproduzieren? Ich erstelle mit Master Pipenv und kann nicht reproduzieren. Ein Docker-Image wäre nach Möglichkeit eine große Hilfe

frostming picture frostming am 28. Okt. 2020

@gregflynn

  1. machte mit 2020.8.13 ein frisches venv

Ist dieser Schritt wichtig, um den Fehler zu reproduzieren? Ich erstelle mit Master Pipenv und kann nicht reproduzieren. Ein Docker-Image wäre nach Möglichkeit eine große Hilfe

Gutes Auge, aber ich habe die folgenden Änderungen vorgenommen und konnte immer noch mit der neuesten Master-Version reproduzieren. Für Schritt 4 habe ich mein Installationsskript aktualisiert:

-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

und bekam noch:

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

Gerne probieren wir noch mehr aus! Vielen Dank

gregflynn picture gregflynn am 28. Okt. 2020

Oh, ich habe es geschafft, es zu reproduzieren! Ich habe nicht bemerkt, dass der kritische Faktor VENV_IN_PROJECT ist.

frostming picture frostming am 29. Okt. 2020

Oh, ich habe es geschafft, es zu reproduzieren! Ich habe nicht bemerkt, dass der kritische Faktor VENV_IN_PROJECT ist.

: raise_hands: tolle Neuigkeiten! Es tut mir leid, dass ich es versäumt habe, Ihnen eine Docker-Datei zu geben. Ich habe diese Notiz bei meiner ersten Lektüre verpasst

gregflynn picture gregflynn am 29. Okt. 2020
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

jacebrowning picture jacebrowning  ·  3Kommentare
ansrivas picture ansrivas  ·  3Kommentare
marc-fez picture marc-fez  ·  3Kommentare
hynek picture hynek  ·  3Kommentare
ipmb picture ipmb  ·  3Kommentare