/cc @uranusjr @ncoghlan @altendky @njsmith

Ich bin davon überzeugt, dass dies häufig vorkommt (Firmen-FW / Caching-Proxy) - ich glaube, wir brauchen eine Überschreibungseinstellung, um einen Spiegel anzugeben, der anstelle von pypi verwendet werden soll, wenn wir ihn in der pipfile finden - wie PIPENV_PYPI_MIRROR oder PIPENV_PYPI_CACHING_PROXY oder so ähnlich, um anzugeben, dass es zuerst versucht werden soll, im Grunde genommen in sources vor pypi geschnitten.

Scheint das das Ziel zu erreichen? Wenn ja, können wir den Implementierungsgeist eintragen, um uns zu sagen, warum das gut oder schlecht ist (@ncoghlan)

Ich beginne mit einem Hinweis zur Vorsicht: bis PyPI einen Paketsignierungsmechanismus ähnlich PEP 458 implementiert hat, um eine TLS-unabhängige Möglichkeit für pip bereitzustellen, um sicherzustellen, dass Pakete, die nominell von PyPI stammen, tatsächlich mit dem übereinstimmen, was PyPI veröffentlicht hat , dann ist das Anbieten der Möglichkeit, Datenverkehr transparent auf einen anderen Server umzuleiten, aus Sicherheitsgründen wirklich besorgniserregend.

Unglücklicherweise ist dieser spezielle Angriffsvektor bereits über pip.conf offen, sodass das Anbieten von etwas Vergleichbarem auf pipenv -Ebene nichts noch schlimmer machen wird, als es bereits ist.

Darüber hinaus denke ich, dass ein Allzweck-Repository-URL-Umschreibungsmechanismus tatsächlich einfacher zu dokumentieren und zu erklären ist als etwas PyPI-spezifisches, zumindest auf der Ebene der Basisfunktionen. Etwas wie:

pipenv --override-source-url 'default=https://pypi-proxy.example.com/api' --override-source-url 'https://pypi.python.org/simple=https://pypi-proxy.example.com/api'  --override-source-url 'https://pypi.org/simple=https://pypi-proxy.example.com/api' install

(Das einzige PyPI-spezifische Bit dort wäre die Verwendung von "default", um auf die Standard-Download-Quelle von pip zu verweisen, wie in pip.conf spezifisch).

Es wäre jedoch in der Praxis unhandlich, jedes Mal die gesamte Quell-URL-Überschreibungszuordnung zu buchstabieren, daher könnten einige Optionen für CLI-Zucker wie folgt aussehen:

pipenv --override-source-urls <config file> install

pipenv --pypi-mirror https://pypi-proxy.example.com/api install

Ob die Ebene --override-source-url sofort verfügbar gemacht werden soll oder nicht, ist eine andere Frage - es könnte sinnvoller sein, zuerst die einfachere Option --pypi-mirror zu implementieren und lediglich die Möglichkeit von --override-source-url und beizubehalten --override-source-urls als mögliche zukünftige Optionen im Auge behalten.

Ein allgemeines {given URL: override URL} -Mapping war auch mein erster Gedanke, aber bei weiterer Betrachtung gibt es einige Argumente für Sonderfälle von PyPI:

• PyPI ist ziemlich einzigartig, da es eine bekannte öffentliche URL und viele Mirrors hat

• PyPI hat tatsächlich mehrere URLs (z. B. werden wir wahrscheinlich eine Weile lang Pipfiles mit https://pypi.python.org/simple und https://pypi.org/simple herumschwirren lassen, und vielleicht auch https://pypi.python.org/simple/ und https://pypi.org/simple/ mit dem abschließenden Schrägstrich?), und es wäre schön, wenn wir das einmal lösen könnten, anstatt jeden Benutzer zu zwingen, es selbst herauszufinden

@njsmith Siehe den Zuckervorschlag --pypi-mirror <URL> im letzten Teil meines Beitrags - wenn sich die anfängliche Implementierung ausschließlich darauf konzentrierte, könnte die allgemeine URL-Umschreibungsfunktion als internes Implementierungsdetail beginnen (angetrieben von der Tatsache, dass " PyPI" hat mehrere URLs, die letztendlich alle an dieselbe Stelle aufgelöst werden) und dann später als eigenständiges Feature zur Verfügung gestellt werden (nachdem bestätigt wurde, dass es wie gewünscht für die primäre Verwendung --pypi-mirror funktioniert Fall).

Ah stimmt, das habe ich übersehen :-)

Gibt es eine allgemeine Regel, die Befehlszeilenargumente einer Art persistenter Konfiguration zuordnet? Ich stelle mir vor, dass die meisten Benutzer es einmal einrichten und dann vergessen würden.

@ncoghlan schrieb:

Ich beginne mit einem Hinweis zur Vorsicht: Bis PyPI einen Paketsignierungsmechanismus ähnlich PEP 458 implementiert hat, um eine TLS-unabhängige Möglichkeit für pip bereitzustellen, um sicherzustellen, dass Pakete, die nominell von PyPI stammen, tatsächlich mit dem übereinstimmen, was PyPI veröffentlicht, und dann die Möglichkeit bieten Datenverkehr transparent auf einen anderen Server umzuleiten, ist aus Sicherheitssicht wirklich besorgniserregend.

Wenn ich mein Pipfile.lock richtig lese, ist keine Beziehung zwischen einem Paket und der Quelle, aus der es installiert wurde, gespeichert. Da das vorhandene Feature-Set die Angabe mehrerer Quellen zulässt, führt dies nicht zu einem ähnlichen Problem? Ein sync könnte am Ende ein Paket aus einer anderen Quelle erhalten als der, die beim Erstellen der Sperrdatei verwendet wurde.

Pipfile.lock speichert eine Liste akzeptabler Artefakt-Hashes für jede gepinnte Abhängigkeit, so dass es schwierig ist, Pakete heimlich zu ersetzen, sobald Sie eine Sperre vorgenommen haben. Wenn Sie sich zum Zeitpunkt der Sperrgenerierung explizit für eine Quelle in Pipfile , heißt das: „Ich vertraue darauf, dass diese Quelle sich nicht mit mir anlegt, und werde TLS verwenden, um zu überprüfen, ob ich tatsächlich mit diesem Ursprungspunkt spreche“. (Ich denke, es gibt irgendwo ein Problem, bei dem die Aussicht diskutiert wird, bestimmte Pakete an bestimmte Quell-Repos zu binden, obwohl es sich möglicherweise eher in pip oder einem der anderen PyPA-Repos als hier befindet.)

Das Ändern der Standard-Index-URL (oder das Hinzufügen einer zusätzlichen Index-URL) in pip.conf oder das Verwenden der hier vorgeschlagenen Überschreibungsfunktion über eine Konfigurationsdatei oder einen Shell-Profil-basierten Mechanismus ist anders: Das heißt: "Ich oder ein beliebiger Prozess I zu einem bestimmten Zeitpunkt mit Schreibzugriff auf mein Home-Verzeichnis lief (z. B. eine sdist-Datei setup.py), entschied, meine Einstellungen so zu konfigurieren, dass dieser Paketquelle vertraut wird". Und selbst ein Signaturschema wie PEP 458 ist kein vollständiger Schutz gegen diese Art von Spielereien, wenn die öffentlichen Schlüssel, die zur Überprüfung verwendet werden, selbst irgendwo in Ihrem Home-Verzeichnis gespeichert sind und nicht in einem Verzeichnis, für dessen Änderung erhöhte Berechtigungen erforderlich sind.

Es gibt gute Gründe, warum Organisationen mit strengen Sicherheitsanforderungen Builds auf gesperrten Servern mit nur eingeschränktem Zugriff auf das Internet im Allgemeinen ausführen oder diese Art von Problemen auf Netzwerkebene auf andere Weise überwachen :)

Beachten Sie auch, wenn Sie mehrere Indizes verwenden und ein Paket aus dem nicht primären Index stammt, wird dies in der Sperrdatei angegeben.

Die pep 458-Bedenken waren im Wesentlichen das, was ich im Sinn hatte, da Dinge, die unterschiedliche URLs sind, aber tatsächlich auf pypi verweisen, anders sind, als wenn Sie pypi nur lokal kopieren und behaupten, es sei dasselbe.

Ich oder ein beliebiger Prozess, den ich zu einem bestimmten Zeitpunkt mit Schreibzugriff auf mein Home-Verzeichnis ausgeführt habe (z. B. die Datei setup.py einer sdist), hat beschlossen, meine Einstellungen so zu konfigurieren, dass dieser Paketquelle vertraut wird

Wenn dies Ihr Bedrohungsmodell ist, sehe ich nicht, wie etwas, das pipenv tun kann, es stark beeinflussen wird. Jemand, der die Konfiguration Ihres Home-Verzeichnisses ändern kann, kann auch Dinge wie das Einfügen eines neuen Verzeichnisses auf $PATH und das Einfügen einer gefälschten Pipenv dort tun, die tut, was sie wollen.

@njsmith Dies ist auch das Bedrohungsmodell von pip, da die Paketinstallation die Ausführung von beliebigem Code aus sdist setup.py -Dateien erfordert. Dieser Code könnte tatsächlich Dinge in Ihrem Home-Verzeichnis wie Ihre Einstellungen überschreiben oder Dinge zu Ihrem Pfad hinzufügen oder eine beliebige Anzahl von Dingen. Aus diesem Grund ist die explizite Privilegierung von pypi (ein bekannter, vertrauenswürdiger Index) und die Anforderung einer Hash-Überprüfung ein guter Schritt in Richtung Sicherheit. Es ermöglicht die zentralisierte Kontrolle und Eliminierung bekannter Sicherheitsbedrohungen und identifiziert die Verifizierung der heruntergeladenen Pakete auf verteilte Weise. Was sagt die von Ihnen heruntergeladene Sperrdatei über den Hash, den Sie erhalten sollten? Es stimmt nicht mit dem überein, was Sie aus dem Index erhalten? Damit dieser Betriebsmodus fehlschlägt, müssen Sie Fehler auf mehr als einem der lokalen Computer-, Index- und Netzwerkebenen haben, da Sie davon sprechen, dass mehrere beschädigte Pakete in Ihrem Anwendungsstapel zusammenarbeiten, um Hashes gegen einen vertrauenswürdigen Index zu überprüfen , und in vielen Fällen stammten die Hashes selbst aus einer weiteren unbeteiligten Quelle. Also müssen Sie jetzt zumindest alle Hash-Checks in pip und pipenv irgendwie manipuliert haben, so dass es Hashes erzeugt, die mit denen identisch sind, auf die Sie hoffen, aber noch andere bösartige Dinge installiert?

Ich denke, was ich sagen will, ist, wenn Ihr lokaler Computer kompromittiert ist, gibt es nichts, was pip oder pipenv tun wird, um Sie zu retten. Aber wir können sicherstellen, dass das Paket, das Sie herunterladen, das ist, nach dem Sie gesucht haben, von dem Ort, an dem Sie danach suchen sollten, was ein Element in der Sicherheitskette darstellen kann.

@ncoghlan @njsmith Wie wirkt sich das alles auf den Schritt aus, gegen sudo pip install... zurückzudrängen, und ich denke, wir alle haben das allgemeine Gefühl, dass Sie wahrscheinlich nicht auch Ihren verwenden sollten, wenn Sie pip verwenden Systempaket-Manager, um Python-Dinge im Großen und Ganzen zu installieren. Dies ist vielleicht nicht wirklich eine Pipenv-Frage, aber hier wird gerade diskutiert, und dies könnte die nächsten Schritte leiten ...

@techalchemy Ich sehe überhaupt keinen Zusammenhang zu diesem Thema? Ich denke, die Schlussfolgerung aus all dem oben Gesagten ist, dass das Überschreiben des Spiegels, den pipenv für PyPI verwendet, keine zusätzlichen Bedrohungen einführt, und sudo pipenv zu tun, macht überhaupt keinen Sinn, oder?

@njsmith nein Ich denke nicht, dass jemand sudo pipenv verwenden sollte, wie ich bereits erwähnt habe, ist es nicht wirklich zum Thema, aber da wir den Pfad des Bedrohungsmodells ein wenig hinuntergegangen sind, dachte ich, es wäre eine Erkundung wert. Speziell:

Und selbst ein Signaturschema wie PEP 458 ist kein vollständiger Schutz gegen diese Art von Spielereien, wenn die öffentlichen Schlüssel, die zur Überprüfung verwendet werden, selbst irgendwo in Ihrem Home-Verzeichnis gespeichert sind und nicht in einem Verzeichnis, für dessen Änderung erhöhte Berechtigungen erforderlich sind.
Es gibt gute Gründe, warum Organisationen mit strengen Sicherheitsanforderungen Builds auf gesperrten Servern mit nur eingeschränktem Zugriff auf das Internet im Allgemeinen ausführen oder diese Art von Problemen auf Netzwerkebene auf andere Weise überwachen :)

Wenn eine Verteidigung zumindest teilweise darauf angewiesen ist, dass Schlüssel an einem privilegierten Ort gespeichert werden, wir aber davon abraten, privilegierte Python-Installationen zu verwenden, denke ich, dass es möglicherweise eine Diskussion wert ist. Vielleicht bin ich falsch. Aber es scheint definitiv mit dem Kommentar von @ncoghlan zusammenzuhängen (aber nicht sudo pipenv , das sollte niemals eine Sache sein)

Ja, das schien wahrscheinlich aus dem Nichts zu kommen, nur ein zufälliger Gedanke. Hoffentlich klärt der zusätzliche Kontext etwas auf

Ich bin dafür, dass wir diese Ausgabe mit dem Thema belassen, Leuten zu helfen, die PyPI-Spiegel verwenden müssen, anstatt in eine spekulative Diskussion darüber zu geraten, wie wir TUF implementieren könnten. (Wie auch immer, ich glaube nicht, dass wir viel tun können oder sollten, um uns gegen einen Angreifer zu verteidigen, der willkürlichen Schreibzugriff auf das Home-Verzeichnis des Benutzers hat.)

Okay, also definieren wir das Verhalten, das wir erwarten oder bevorzugen würden. Mein aktuelles Arbeitsverständnis ist folgendes:

• Wenn --pypi-mirror übergeben oder PIPENV_PYPI_MIRROR gesetzt ist, sollten wir das bevorzugen
• Sollten wir es nur PyPI vorziehen? Wie beurteilen wir, ob eine bestimmte Index-URL „PyPI“ ist – wir können sie nicht abfragen, also müssten wir eine Liste führen
• Soll die Liste alle möglichen Permutationen enthalten, oder sollten wir uns damit begnügen, die beiden URLs, die wir in der Vergangenheit zum Generieren von Pipfiles verwendet haben, als Dinge zu verwenden, für die wir zuerst den bereitgestellten Spiegel ausprobieren sollten?

Es sollte nur PyPI überschreiben, keine anderen URLs. Ich schätze, es werden wahrscheinlich nur ein paar verschiedene PyPI-URLs verwendet, also können sie aufgelistet werden, und wenn wir eine vermissen, wird jemand einen Fehler melden, er wird hinzugefügt, und ziemlich bald werden wir alle haben.

Scheint mir der richtige Ansatz zu sein.

Was @njsmith gesagt hat, entspricht auch meiner Perspektive. Die 3 Repo-URLs, die ich vorschlagen würde, in einer ersten PR zu ersetzen, wären:

• Keine festgelegt (dh wenn man sich auf die Standardeinstellung von pip verlässt)
• https://pypi.python.org/simple
• https://pypi.org/simple

Der abschließende Schrägstrich oder nicht wird wahrscheinlich besser als URL-Normalisierungsschritt behandelt, anstatt die URLs separat aufzulisten.

Beachten Sie, dass die Anfragen Pipfile (zum Zeitpunkt des Schreibens) einen nachgestellten Schrägstrich haben , also müssen wir dies wahrscheinlich auf die eine oder andere Weise handhaben.

Stimmt, mein Gedanke war:

• Pflegen Sie eine Liste von URLs ohne nachgestellte Schrägstriche
• Überprüfen Sie eingehende URLs auf einen nachgestellten Schrägstrich und entfernen Sie ihn, wenn Sie ihn finden ( str.rstrip wäre wahrscheinlich gut genug für die Aufgabe, obwohl er eine beliebige Anzahl nachgestellter Schrägstriche entfernen würde, oder wir könnten es strenger angehen, und höchstens einen abschließenden Schrägstrich entfernen)

Genial. Ich denke, das ist genug, um damit zu arbeiten und einfach genug zu bauen. Danke an alle!

Ich hoffe, dass die Spiegelfunktion bald hinzugefügt werden kann~

Ich stoße auch auf dieses Problem. Die Situation ist:

• Haben Sie einen internen PyPI-Server mit einigen privaten Paketen.
• Haben Sie mehrere Python-Anwendungen, die Pipenv verwenden, um ihre Abhängigkeiten zu verwalten.
• Einige der Abhängigkeiten leben auf dem internen PyPI-Server und andere auf dem Community-PyPI. Der interne leitet bei nicht gefundenen Paketen zum Community-PyPI um.

Meine Bereitstellungsstrategie richtet bereits eine systemweite pip.conf ein, die auf den internen PyPI-Server verweist. Überraschenderweise habe ich festgestellt, dass diese Konfiguration von Pipenv ignoriert wird.

Mir ist aufgefallen, dass, wenn ich das interne PyPI verschieben/umbenennen würde, mehrere Anwendungen mit Pipfiles aktualisiert und ihre Pipfile.lock-Dateien neu generiert werden müssten. Eine Spiegeloption würde die gewünschte Funktionalität bereitstellen. Es würde auch funktionieren und sich weniger überflüssig anfühlen, wenn Pipenv einfach die Systemkonfiguration für Pip lesen könnte.

PRs willkommen auf diesem übrigens

Hallo. Ich habe das gleiche Bedürfnis, aber ich würde diese Override-Funktion in ein anderes Ticket aufteilen.

Hier ist mein erwarteter Verhaltensvorschlag:

• Eine Konfigurationsdatei kann definiert werden, um jeden Wert festzulegen, der im Abschnitt [[source]] der Pipfile definiert ist.
• könnte eine toml-Datei sein, die nur den Abschnitt [[source]] der Pipfile enthält
• Der Speicherort dieser Datei ist stark von den für pip.conf definierten Regeln inspiriert (z. B.: /etc/pipenrc.toml, ~/.pipenvrc.toml
• Umgebungsvariablen könnten auch definiert werden, um diese Werte zu überschreiben (Erinnerung: Wir brauchen alle Werte von [[source]]). Zu definieren
• Das aktuelle Verhalten von pipenv ist jetzt:
  
  
  
  • Beim Erstellen eines Pipfiles werden die Werte aus der Konfigurationsdatei / Umgebungsvariable übernommen
  
  
  • Wenn keine Konfigurationsdatei oder Umgebungsvariable definiert ist, gilt das aktuelle Verhalten von pipenv
  
  
  • pipenv generiert weiterhin immer den [[source]]-Abschnitt der Pipfile
  
  
  • wenn ein [[source]]-Abschnitt der Pipfile vorhanden ist, versucht pipenv nicht, irgendetwas mit Werten aus der Konfigurationsdatei zu überschreiben.
  
  

Und in einem zweiten Ticket können die —Override-Optionen implementiert werden. Sinnvoll ist es zum Beispiel in einem CI oder so.

Als Randnotiz: Wir verwenden pipenv jetzt stark in der Produktion, aber ich muss alle zu oft daran erinnern, dass sie ihre Pipfile manuell ändern müssen, wenn sie ein neues Projekt starten, um auf unser Arrifactory Pypi-Repository zuzugreifen (zur Information, Nexus erstellt auch eine Pypi Cache kostenlos und funktioniert super!). Wir haben eine sehr einschränkende Firewall und es ist eine sehr gute Praxis innerhalb eines Unternehmens, externe Abhängigkeiten zwischenzuspeichern, damit sie gesichert und beispielsweise auf Schwachstellen überprüft werden können.
Wenn eine einfache Funktion ähnlich der allgemeinen oder Benutzerkonfigurationsdatei (wie wir es bereits für pip oder npm tun), damit wir sie auf allen unseren Workstations bereitstellen, damit unsere Entwickler weniger Fehler machen, wäre das perfekt für mich)

Vielleicht habe ich etwas verpasst, aber das scheint eine Regression zu sein. Wir sind seit einiger Zeit auf 11.6.0 und haben pipenv gerne an die Einstellungen in unserer pip.conf delegiert, die auf einen internen Pypi-Spiegel zeigen.

Irgendeine Ahnung wann das kaputt gegangen ist? Es macht pipenv in unserem Kontext völlig unbrauchbar. Ich habe Probleme, dies als "fehlendes Feature" zu sehen, obwohl es scheinbar lange Zeit gut funktioniert hat.

Um es klar zu sagen: Nach dem Upgrade auf 2018.05.18 versucht pipenv, selbst mit dem in unserem Pipfile[.lock] angegebenen Spiegel, neue Pakete von pypi.org zu installieren.

Vielleicht ist das, was ich sehe, ein anderes Problem als dieses ...

@brettdh Es ist schwer zu sagen, ohne Ihre Umgebung zu sehen, aber ich würde denken, dass es nicht dasselbe Problem ist. Ich würde vorschlagen, dass Sie zwischen den Veröffentlichungen halbieren, um genau zu sehen, wo sich dies geändert hat, und ein neues Problem dafür eröffnen.

Ich arbeite an der PR dafür.

Ich denke, dies wurde gegenüber der Standardeinstellung rückgängig gemacht. Es ist vielleicht in eine Welle von Updates für Pip 10 geraten, die noch nicht veröffentlicht wurden, aber ich glaube, wir können das ohne allzu große Schwierigkeiten aufgreifen, wenn @JacobHenner es nicht bereits hinzufügt

Ich nehme an, Sie sprechen von der Verwendung von devpi als Caching-Proxy für das offizielle PyPi. Für pip selbst müssten Sie /etc/pip.conf und /usr/lib64/python3.6/disutils/distutils.cfg ändern, damit pip Ihren lokalen devpi-Server für alle Anfragen verwendet.

Es sieht jedoch so aus, als würde pipenv diese systemweiten Einstellungen ignorieren , sodass Sie gezwungen sind, die Konfigurationseinstellung [[source]] in Pipfile zu ändern, um auf Ihren devpi-Server zu verweisen. Aber wenn Sie Ihr Pipfile extern veröffentlichen, müssen externe Mitwirkende Ihre [[source]] -Einstellungen entfernen, um tatsächlich ihre eigene Umgebung zu erstellen.

Ich denke, dass pipenv nur die globalen Einstellungen von /etc/pip.conf und /usr/lib.../distutils.cfg respektieren sollte

@polski-g

Ich nehme an, Sie sprechen von der Verwendung von devpi als Caching-Proxy für das offizielle PyPi

Nexus Repository, aber ja, dieselbe Idee.

Es sieht jedoch so aus, als würde pipenv diese systemweiten Einstellungen ignorieren

Wie @techalchemy erwähnte, glaube ich, dass pipenv (11.6.0) früher pip.conf (auch homedir) respektierte, aber die neueste Version nicht - insbesondere gibt es irgendwo eine hartcodierte pypi.org-URL (dependency Auflösung, IIRC), die nicht überschrieben werden können.

Ich denke, dass pipenv nur die globalen Einstellungen von /etc/pip.conf und /usr/lib.../distutils.cfg respektieren sollte

Einverstanden - obwohl ich persönlich distutils.cfg in meinem Anwendungsfall nicht ändern musste.

IIRC gab es eine Auflösung, pip.conf nicht zu respektieren, aber Sie müssen tief in den Issue-Tracker eintauchen, um ihn zu finden. Auf jeden Fall ist das Schiff gesegelt, und da die PyPI-Spiegelung fast abgeschlossen ist, wird sich dies in naher Zukunft wahrscheinlich nicht ändern.

Ich bin ziemlich zuversichtlich, dass diese Funktion in der nächsten Version ausgeliefert wird (die mit etwas Glück in den nächsten ein oder zwei Tagen ausgeliefert wird).

Ich bin mir auch nicht sicher, aber es ist möglich, dass wir nur .load() aufrufen müssen, nachdem wir den Konfigurationsparser hier erstellt haben, um die Konfigurationsstandardwerte zu erhalten

https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L573 -#L577

@uranusjr Solange die Spiegelungskonfiguration funktioniert (dh nicht die von mir erwähnte fest codierte pypi.org-URL verwendet), sehe ich kein Problem damit, dass pipenv eine eigene Konfiguration dafür hat und Pips ignoriert.

@brettdh Könnten Sie meine Filiale auschecken und bestätigen, dass sie Ihrer entspricht
Anwendungsfall in Ihrer Umgebung?

>

@JacobHenner ja, danke. Meine ersten Tests mit der Option --pypi-mirror ( pipenv install , pipenv lock ) scheinen gut zu funktionieren. Ich habe einen kleinen Vorschlag auf der PR hinterlassen.

Ich bin jedoch etwas besorgt, dass hartcodierte URLs zu pypi.org immer noch über die pipenv-Quellen verstreut erscheinen. Ich kann nicht sicher sein, welche korrekt von [[source]] -Einträgen überschrieben werden, und ich kann mich nicht genau erinnern, welcher Workflow mein obiges Problem verursacht hat. Es ist also schwer zu sagen, ob es behoben ist. 😬

Ja, nach dieser Veröffentlichung plane ich eine größere Code-Bereinigung. Cli-Zeug, das auf das Cli verschoben wird, dort Ausnahmen blubbert und dort alle Exits behandelt, duplizierten Code dedupliziert usw. Es wird eine Menge Arbeit sein und Hilfe wird geschätzt, wenn sich jemand freiwillig melden möchte :p

Ich habe gerade die neueste Version gezogen und pypi.org ist immer noch in den Quellen fest codiert. Ist das Ziel, die Umgebungsvariable oder den Pypi-Spiegel zu nehmen und dies als Standard für [[source]] zu setzen?

bearbeiten:

Ich habe gerade den Code durchforstet. Sieht so aus, als hätten Sie es getan

if PIPENV_TEST_INDEX:
    DEFAULT_SOURCE = {
        u"url": PIPENV_TEST_INDEX,
        u"verify_ssl": True,
        u"name": u"custom",
    }
else:
    DEFAULT_SOURCE = {
        u"url": u"https://pypi.org/simple",
        u"verify_ssl": True,
        u"name": u"pypi",
    }

Ich denke, wenn Sie das If PIPENV_TEST_INDEX in die Umgebungsvariable PIPENV_PYPI_MIRROR ändern, wäre dies ein guter Anfang

Die hier diskutierte Lösung ist seit langem implementiert. Das von Ihnen zitierte Snippet ist ein Standard , dh es wird verwendet, wenn Sie beim Erstellen des Pipfiles keine Quelle angeben.

Nein, die Quelle sollte sich im Pipfile nicht ändern. Das Ziel dieser Änderung
war es, Benutzern zu ermöglichen, PyPI-URLs mit einem Spiegel zu überschreiben, _ohne_ sich zu ändern
die Pipfile.

@JacobHenner Der Mirror-Handling-Code verarbeitet die Quellliste nach und ersetzt pypi.org -URLs durch Verweise auf den angegebenen Mirror.

Dadurch kann die Überschreibung des Spiegels auch dann funktionieren , wenn es einen expliziten pypi.org -Eintrag in Pipfile gibt. pipenv verlässt sich dann auf dieselbe Logik, um auch seine eigene Standardquelle zu überschreiben.

Wenn es derzeit Fälle gibt, in denen diese Nachbearbeitung nicht korrekt angewendet wird, handelt es sich eher um einen neuen Fehlerbericht für die bereits implementierte Funktion als um eine Funktionsanfrage.

Ich denke, der letzte Kommentar war für @kylecribbs bestimmt?

@JacobHenner Ah, tut mir leid - ich habe Ihren Kommentar falsch interpretiert, indem ich sagte, dass diese Änderung ihr ursprüngliches Ziel nicht erreicht hatte, und nicht als Antwort auf Kyle, die darauf abzielte, klarzustellen, was dieses Ergebnis tatsächlich war.