Pip: Index-URLs, die ein nicht entkoppeltes "@" im Benutzernamen enthalten, verursachen den Fehler "Fehler beim Parsen" in Pip 19.2

+1
Jep. Ist uns auch passiert.

Wir haben auch Probleme mit pip-19.2, wenn wir eine bestimmte Index-URL verwenden:

Looking in indexes: https://<email.com>:****@<artifactory_host>/artifactory/api/pypi/pypi-virtual/simple
Collecting setuptools
ERROR: Could not install packages due to an EnvironmentError: Failed to parse: https://<email.com>:[secure]@<artifactory_host>/artifactory/api/pypi/pypi-virtual/simple/setuptools/

Es funktioniert gut mit pip-19.1.1. Könnte es verwandt sein?

@TTRh sah gerade das gleiche und öffnete # 6776. Ich bin mir nicht sicher, ob es in derselben Ausgabe behandelt werden soll.

@bomri , kannst du bitte mit --verbose erneut ausführen und die Ausgabe bereitstellen?

Könnte verwandt sein mit:
https://github.com/urllib3/urllib3/issues/1640
https://github.com/urllib3/urllib3/pull/1586

Wir hatten das gleiche Problem mit einem Sonderzeichen in unserem Passwort.

Hallo Leute! Vielen Dank, dass Sie dieses Problem eingereicht und sich hier angemeldet haben.

Wenn Sie mit diesem Problem konfrontiert sind, verwenden Sie am besten die Reaktionen von GitHub im ersten Beitrag und abonnieren Sie dieses Problem. Auf diese Weise können wir "Ich auch" -Kommentare vermeiden, die der Diskussion nicht wirklich viel Wert verleihen.

Dies erleichtert es den Betreuern, in diesem Problem selbst zu besprechen, wie dieses Problem behoben werden kann, und Updates für Sie einfacher bereitzustellen. 🙃

@chrahunt läuft mit --verbose Ich bekomme 404 auf pypi.org wie erwartet (da das Paket dort nicht existiert), aber von meinem eigenen Pypi-Server bekomme ich:

403 Client-Fehler: Verboten für URL: ...

Vielleicht hängt es mit Sonderzeichen in der Token-ID zusammen, wie @brainerazer erwähnt

Das hat uns auch gebissen. Ich bin mir nicht sicher, ob dieses Problem mit denen von urllib3 verlinkt sind. Unser Problem tritt auf, wenn versucht wird, ein veröffentlichtes .zip -Paket von GitHub mit einem Zugriffstoken herunterzuladen. Sachen wie pip install https://<my-access-token>@github.com/myorganization/myprivaterepo/archive/myrelease.zip#egg=mypackage funktionieren also nicht mehr mit Pip 19.2 (funktioniert für 19.1.1, wie bereits erwähnt).

Ich habe ein leeres privates Repo erstellt, mit einer leeren Version, um das zu testen. Die Ausgabe für pip install -vvv ... finden Sie hier:

• für pip 19.2 ,
• für pip 19.1.1 (mit dem erwarteten Fehler setup.py nicht gefunden).

Das Problem / der Unterschied kann bei Starting new HTTPS connection (1): github.com:443 .

Vielleicht weiß @cjerdonek mehr über dieses Zeug als ich.

Ich habe für dieses Problem auch eine git bisect -Sitzung durchgeführt, die auf dieses Commit https://github.com/pypa/pip/commit/eeb74aeb29~~ c63ee61027fe

Meine Gedanken: Das aktuelle Verhalten ist technisch korrekter und die Leute sollten anfangen, die neue Schlüsselringunterstützung für dieses Zeug zu verwenden.

Gleichzeitig ist es definitiv nicht schön, dass dies bestehende vernünftige Workflows gebrochen hat. Ich denke, wenn jemand herausfinden kann, wie er das alte Verhalten hier wieder einführen kann, wäre das großartig.

Basierend auf der dokumentierten Abschreibungsrichtlinie von pip benötigen wir keinen Abschreibungszyklus für solche undokumentierten Verhaltensweisen. Trotzdem sollten wir einen Verfallszyklus durchführen und die Benutzer warnen, hier auf die "korrektere" Syntax oder das korrektere Tooling umzuschalten, bevor wir die Unterstützung einstellen und zu einer schöneren Fehlermeldung wechseln.

Ich bin mir nicht sicher, ob die Halbierung hier das richtige Commit gefunden hat, aber trotzdem, danke dafür!

@pradyunsg , vielleicht hinweisen ?
Wenn wir die Art und Weise, wie wir Repos von Drittanbietern verwenden (in unserem Fall gemfury.com), umgestalten müssen, ist das in Ordnung. Ich verstehe einfach nicht, wie die richtige Syntax lauten soll :)

Ich bin mir nicht sicher, ob die Halbierung hier das richtige Commit gefunden hat, aber trotzdem, danke dafür!

Du hast vollkommen recht. Ich habe mein Testskript korrigiert und jetzt zeigt es auf c63ee61027fe, was jetzt wohl sinnvoller ist

Das gleiche Problem bekommen

pip install --user --index-url https://[email protected]:[email protected]/foo/api/pypi/PyPi-dev/simple -v em-generate-config 
Created temporary directory: /tmp/pip-ephem-wheel-cache-1q06a68y 
Created temporary directory: /tmp/pip-req-tracker-1igksn7z 
Created requirements tracker '/tmp/pip-req-tracker-1igksn7z' 
Created temporary directory: /tmp/pip-install-six90fkc 
Looking in indexes: https://rnc_build%40foo.com:****@foo.jfrog.io/foo/api/pypi/PyPi-dev/simple 
Collecting em-generate-config 
  1 location(s) to search for versions of em-generate-config: 
  * https://rnc_build%40foo.com:****@bar.jfrog.io/foo/api/pypi/PyPi-dev/simple/em-generate-config/ 
  Getting page https://rnc_build%40foo.com:****@bar.jfrog.io/foo/api/pypi/PyPi-dev/simple/em-generate-config/ 
ERROR: Could not install packages due to an EnvironmentError. 
Traceback (most recent call last): 
  File "/usr/local/lib/python3.7/site-packages/pip/_vendor/requests/models.py", line 379, in prepare_url 
    scheme, auth, host, port, path, query, fragment = parse_url(url) 
  File "/usr/local/lib/python3.7/site-packages/pip/_vendor/urllib3/util/url.py", line 234, in parse_url 
    raise LocationParseError(url) 
pip._vendor.urllib3.exceptions.LocationParseError: Failed to parse: https://[email protected]:[email protected]/foo/api/pypi/PyPi-dev/simple/em-generate-config/

Kannst du mich bitte auf das benötigte "aktuelle Verhalten" hinweisen?

Hoppla. Ja. (Deshalb brauchte ich ein Nickerchen)

Das Problem hierbei ist, dass die Teile einer URL ... urlencodiert sein sollten.

Daher sollte das @ in der als Benutzername verwendeten E-Mail %40 . Das Folgende ist in der Tat keine gültige URL, die auf dem RFC basiert, der diese Dinge definiert:

https://[email protected]:[email protected]/pypi

Die korrekte Darstellung dieser Informationen wäre:

https://awesome%40pradyunsg.me:[email protected]/pypi

Wenn jemand ein Problem damit hat ... sollte er das wahrscheinlich mit den Leuten besprechen, die diesen RFC geschrieben haben. Es wird in der urllib-Ausgabe erwähnt, die weiter oben in diesem Thread verlinkt ist.

Nebenbei : Problemumgehung hingewiesen, das als Duplikat davon geschlossen wurde.

Was ich in diesem Kommentar vorschlage ... ist, dass pip erkennen könnte, wenn der Benutzer solche ungültigen URLs verwendet (da dies in der Vergangenheit akzeptiert wurde), den Benutzer warnen und wie 19.1.1 arbeiten könnte - nach einigen Mit der Zeit würden die Warnung und die Problemumgehung entfernt.

Wenn Sie glauben, dass dies nach diesem Bruch notwendig ist, lassen Sie es uns wissen.

Gerne überspringe ich die zusätzliche Arbeit, wenn sie für die Betroffenen nicht hilfreich ist. Es macht keinen Sinn, Dinge zu tun, die für die Endbenutzer nicht nützlich sind. 🙃

Ich habe mein Testskript korrigiert und jetzt zeigt es auf c63ee61, was jetzt wohl sinnvoller ist

Tatsächlich. Ich kann dort sehen, warum wir diese Verwendungen nicht früher abgefangen haben - pip hat die Authentifizierungsinformationen der Index-URL "selbst entwickelt" verarbeitet, was eine solche Eingabe offensichtlich nicht für ungültig hielt. Was sich geändert hat, ist, dass wir jetzt eine urllib-Dienstprogrammfunktion verwenden, um Teile der URL abzurufen, die strenger und RFC-kompatibel ist.

pip hat die Authentifizierungsinformationen der Index-URL "selbst entwickelt" verarbeitet, was eine solche Eingabe offensichtlich nicht für ungültig hielt. Was sich geändert hat, ist, dass wir jetzt eine urllib3-Dienstprogrammfunktion verwenden, um Teile der URL abzurufen, die strenger und RFC-kompatibel ist.

Richtig, jetzt verstehe ich es, danke @pradyunsg. Für diejenigen, die zu Hause zuschauen;) als Fix kann man https://<my-access-token>:@github.com/myorganization/myprivaterepo/archive/myrelease.zip#egg=mypackage (beachten Sie das : nach dem Zugriffstoken), wodurch die URL RFC-konformer wird (oder?) Und pip wird glücklich installiert das Paket.

BEARBEITEN:
oder (noch besser) https://:<my-access-token>@github.com/...

macht die URL RFC-konformer (oder?)

Keine Ahnung. Ich bin kein Fachexperte.

Alles, was ich oben gesagt habe, ist im Grunde eine gut informierte Vermutung, die ich gemacht habe, indem ich mir alle relevanten Code-Teile auf meinem Telefon angesehen habe ... weil mein Laptop zu weit vom Bett entfernt ist. 🙃

https: //: @ github.com / myorganization / myprivaterepo /

Das Letzte, was ich hier basierend auf (nur) Intuition + Speicher sagen werde, scheint, als würde pip fälschlicherweise erfordern, dass beide Benutzernamen- / Passwortkomponenten vorhanden sind.

Wenn dies der Fall ist, handelt es sich mit ziemlicher Sicherheit um einen Fehler, wenn auch um einen separaten.

Ich habe versucht, @slafs letzten Kommentar und es scheint gut für mich zu funktionieren.
Das Hinzufügen von ":", nachdem das Token funktioniert, während das Hinzufügen vor dem Token nicht funktioniert

Das Hinzufügen von ":", nachdem das Token funktioniert, während das Hinzufügen vor dem Token nicht funktioniert

Richtig, ich bin mir nicht sicher, warum es bei mir funktioniert (dh bei Pip), aber jetzt sehe ich, dass ein einfaches curl -L das Paket nicht herunterlädt, wenn das : vor dem Token liegt.

Wenn dies der Fall ist, handelt es sich mit ziemlicher Sicherheit um einen Fehler, wenn auch um einen separaten.

Ja, ich neige jetzt dazu zu glauben, dass es auch völlig in Ordnung ist, kein : im Auth-Bereich der URL zu haben. Ich meine, curl beschwert sich nicht. urllib3 :

>>> import urllib3
>>> urllib3.__version__
'1.25.3'
>>> urllib3.util.parse_url('http://user<strong i="16">@host</strong>')
Url(scheme='http', auth='user', host='host', port=None, path=None, query=None, fragment=None)

Ich denke, ich werde ein Problem dazu einreichen.

Ich denke, ich werde ein Problem dazu einreichen.

Bitte. :) :)

Können Sie für Personen, die sich bereits damit befasst haben, eine Verknüpfung zu der Codezeile herstellen, in der die Analyse durchgeführt wird?

@cjerdonek Ich bin mir nicht sicher, ob ich eine genaue Linie für dich habe. Wenn ich kurz auf c63ee61027fe7dea schaue, kann ich nur erkennen, dass https://github.com/pypa/pip/blob/81040b5d0644460a46a360d67c451c03bbbb03ab/src/pip/_internal/download.py#L333 -L335 für mich verdächtig aussieht. Speziell im Vergleich zur vorherigen Version dieser Datei: https://github.com/pypa/pip/blob/e34769861ec5ed8aa5ce23670e111fe8db446c39/pip/download.py#L91 -L96

Oh, sorry @cjerdonek , Sie fragen wahrscheinlich nach dem Problem mit nicht codierten @ . Ich habe mich auf mein Problem mit dem Authentifizierungstoken bezogen.

Ich denke auch, wir sollten offen sein für die Möglichkeit, dass es hier zwei Probleme gibt. In diesem Kommentar (zweite Antwort auf den ursprünglichen Beitrag) gibt es einen Analysefehler in den Protokollen (offensichtlich von urllib3 basierend auf dem Text "Fehler beim Parsen"):

FEHLER: Pakete konnten aufgrund eines Umgebungsfehlers nicht installiert werden: Fehler beim Parsen: https://<email.com>:[secure]@<artifactory_host>/artifactory/api/pypi/pypi-virtual/simple/setuptools/

Im ursprünglichen Beitrag wurde jedoch der Fehler "Keine übereinstimmende Verteilung für Paketname gefunden" ohne den Fehler "Fehler beim Parsen" in den Protokollen gemeldet (es sei denn, dieser war in den Protokollen vorhanden, aber einfach nicht im Bericht enthalten).

Es wäre gut, die Stapelverfolgung an der Stelle des ersten Fehlers oben zu kennen.

Hmm ... Scheint, als ob meine Intuition nicht genau richtig war. Hah!

@cjerdonek Ich bezog mich auf das Parsen in MultiDomainBasicAuth .__ call__, aber ich sehe jetzt, dass es tatsächlich die Parsing-Dienstprogramme von urllib verwendete. Das Seltsame, das mich abschreckte, war die Verkettung, aber ich denke, das ist ... in Ordnung?

ISTM jetzt, da die Bedingung, auf die @slafs hingewiesen hat, die Hauptursache dafür sein könnte - sie wird so or anstelle von and , und or "" im Aufruf sollte das Problem mit den Auth-Needs-2-Teilen sowie diesen Bericht beheben, denke ich.

Hier ist der vollständige Traceback, als ich den Fehler "Fehler beim Parsen" mit einer erfundenen Extra-Index-URL reproduzierte (ich glaube, der ausführliche Modus bewirkt, dass der Traceback angezeigt wird):

$ pip install twine --extra-index-url https://[email protected]:[email protected]/simple/ -vvv
...
  Getting page https://foo%40example.com:****@github.com/simple/twine/
ERROR: Could not install packages due to an EnvironmentError.
Traceback (most recent call last):
  File "/.../pip/src/pip/_vendor/requests/models.py", line 379, in prepare_url
    scheme, auth, host, port, path, query, fragment = parse_url(url)
  File "/.../pip/src/pip/_vendor/urllib3/util/url.py", line 234, in parse_url
    raise LocationParseError(url)
pip._vendor.urllib3.exceptions.LocationParseError: Failed to parse: https://[email protected]:[email protected]/simple/twine/

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../pip/src/pip/_internal/commands/install.py", line 345, in run
    resolver.resolve(requirement_set)
  File "/.../pip/src/pip/_internal/legacy_resolve.py", line 196, in resolve
    self._resolve_one(requirement_set, req)
  File "/.../pip/src/pip/_internal/legacy_resolve.py", line 359, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/.../pip/src/pip/_internal/legacy_resolve.py", line 307, in _get_abstract_dist_for
    self.require_hashes
  File "/.../pip/src/pip/_internal/operations/prepare.py", line 134, in prepare_linked_requirement
    req.populate_link(finder, upgrade_allowed, require_hashes)
  File "/.../pip/src/pip/_internal/req/req_install.py", line 211, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "/.../pip/src/pip/_internal/index.py", line 1201, in find_requirement
    req.name, specifier=req.specifier, hashes=hashes,
  File "/.../pip/src/pip/_internal/index.py", line 1183, in find_candidates
    candidates = self.find_all_candidates(project_name)
  File "/.../pip/src/pip/_internal/index.py", line 1128, in find_all_candidates
    for page in self._get_pages(url_locations, project_name):
  File "/.../pip/src/pip/_internal/index.py", line 1282, in _get_pages
    page = _get_html_page(location, session=self.session)
  File "/.../pip/src/pip/_internal/index.py", line 234, in _get_html_page
    resp = _get_html_response(url, session=session)
  File "/.../pip/src/pip/_internal/index.py", line 182, in _get_html_response
    "Cache-Control": "max-age=0",
  File "/.../pip/src/pip/_vendor/requests/sessions.py", line 546, in get
    return self.request('GET', url, **kwargs)
  File "/.../pip/src/pip/_internal/download.py", line 610, in request
    return super(PipSession, self).request(method, url, *args, **kwargs)
  File "/.../pip/src/pip/_vendor/requests/sessions.py", line 519, in request
    prep = self.prepare_request(req)
  File "/.../pip/src/pip/_vendor/requests/sessions.py", line 462, in prepare_request
    hooks=merge_hooks(request.hooks, self.hooks),
  File "/.../pip/src/pip/_vendor/requests/models.py", line 313, in prepare
    self.prepare_url(url, params)
  File "/.../pip/src/pip/_vendor/requests/models.py", line 381, in prepare_url
    raise InvalidURL(*e.args)
pip._vendor.requests.exceptions.InvalidURL: Failed to parse: https://[email protected]:[email protected]/simple/twine/

Interessanterweise, wie Sie aus der ersten Protokollmeldung oben sehen können:

Abrufen der Seite * *@github.com/simple/twine/

Unser eigener Protokollierungscode schafft es, das Zeichen im Benutzernamen zu zitieren, das, wenn es in der tatsächlichen Anfrage zitiert würde, meines Erachtens (eines) der Probleme lösen würde. Das Angebot für die Protokollierung erfolgt in redact_netloc() : https://github.com/pypa/pip/blob/81040b5d0644460a46a360d67c451c03bbbb03ab/src/pip/_internal/utils/misc.py#L1109 -L1122

heh, über das letzte habe ich auch festgestellt, dass pip das passwort nicht immer redigiert. Wenn Sie die Anmeldeinformationen in "gültige" ändern, erhalten Sie nach pip install z

$ pip install https://foo:[email protected]/slafs
Collecting https://foo:****@github.com/slafs
  Downloading https://foo:[email protected]/slafs
...

😅

@ pypa / pip-committers Also für den Fehler, der durch die strengere URL-Analyse verursacht wurde, die durch das Hersteller-Update von urllib3 v1.25 eingeführt wurde (Original-PR https://github.com/urllib3/urllib3/pull/1487 mit Folgeproblem https: //github.com/urllib3/urllib3/issues/1640), möchten wir die Dinge so lassen, wie sie sind, und verlangen, dass Benutzer die Dinge richtig zitieren (es scheint nicht, dass sich urllib3 ändert), oder wollen wir "reparieren"? die URL, die der Benutzer angegeben hat, indem er etwas wie das getan hat, was in redact_netloc() oben getan wurde? Wenn Sie zur vorherigen Logik zurückkehren, ohne die vom Benutzer bereitgestellte URL zu korrigieren, müssen Sie das Hersteller-Update von urllib3 zurücksetzen. Ich bin mir nicht sicher, ob wir dies tun möchten.

heh, über das letzte habe ich auch festgestellt, dass pip das passwort nicht immer redigiert.

Sie können dies als separates Problem einreichen. pip hat derzeit keine "globale" Möglichkeit, dies zu tun. Es gibt ein paar ähnliche Fälle, von denen ich glaube, dass sie als Pip-Probleme existieren.

Wollen wir die Dinge so lassen, wie sie sind, und verlangen, dass Benutzer die Dinge richtig zitieren?

Wenn die Benutzer, die dieses Problem eingereicht haben, sagen, dass das Zitieren des @ für sie komplex ist, würde ich sagen, dass wir eine Problemumgehung für urllib3 hinzufügen.

Ich bin kein Fan der Idee, um urllib3 herumzuarbeiten, obwohl ich es schon einmal vorgeschlagen habe.

Ich stimme zu - ich würde es vorziehen, die URL nicht zu "reparieren", es ist wahrscheinlich fragiler Code, den wir pflegen müssten, aber wenn das Zitieren des @ für die tatsächlich von diesem Problem betroffenen Benutzer komplex ist, sollten wir das tun, was wir tun können ihre Schmerzen lindern.

Ich würde jedoch gerne eine vorübergehende Problemumgehung durchführen und einen Prozess zum Verwerfen nicht konformer URLs starten (damit die Benutzer Zeit haben, dies zu beheben, die Problemumgehung jedoch nicht auf unbestimmte Zeit beibehalten).

Für das, was es wert ist, sieht es so aus, als würden Schnur-Uploads nicht funktionieren, wenn Sie einen Benutzernamen mit dem %40 anstelle eines @ . In meinem Fall habe ich einen PyPI-Benutzernamen in meiner geheimen Speicher-Engine gespeichert. Wenn ich diesen Benutzernamen auf foo%40bar.com aktualisiere, funktionieren meine Pip-Installationen, mein Twine-Upload (der denselben Berechtigungsnachweis verwendet) schlägt jedoch fehl:

twine upload --verbose --repository-url https://mypypi.com -u foo%40bar.com -p <redacted> dist/my-package-*
Uploading distributions to https://mypypi.com
Uploading my-package-1.2.3.tar.gz

100% 166k/166k [00:00<00:00, 430kB/s]  
Content received from server:
<html>
 <head>
  <title>401 Unauthorized</title>
 </head>
 <body>
  <h1>401 Unauthorized</h1>
  This server could not verify that you are authorized to access the document you requested.  Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.<br/><br/>

Ich sehe ein separates, aber ähnliches Problem, bei dem --extra-index-url fehlschlägt, wenn eine Autorisierung vorliegt. Nicht nur von @ entkommen.

Verwenden von:
Python 3.7.4
pip 19.2.1

1. Wenn Sie die Autorisierung entfernen und das Paket in unserem privaten Repo veröffentlichen, können Sie es herunterladen
2. Ein Downgrade auf Pip 19.1.1 löst natürlich auch das Problem

pip3 install package --extra-index-url https://[email protected]/pypi -vvv

Zurück verfolgen:

Created temporary directory: /private/var/folders/rb/rg18vqd16lxg47cm1kvgh3yh0000gn/T/pip-ephem-wheel-cache-dkqjnspg
Created temporary directory: /private/var/folders/rb/rg18vqd16lxg47cm1kvgh3yh0000gn/T/pip-req-tracker-_5f9p1zv
Created requirements tracker '/private/var/folders/rb/rg18vqd16lxg47cm1kvgh3yh0000gn/T/pip-req-tracker-_5f9p1zv'
Created temporary directory: /private/var/folders/rb/rg18vqd16lxg47cm1kvgh3yh0000gn/T/pip-install-ajhlm6xm
Looking in indexes: https://pypi.org/simple, https://[email protected]/pypi
Collecting package
  2 location(s) to search for versions of package:
  * https://pypi.org/simple/package/
  * https://[email protected]/pypi/package/
  Getting page https://pypi.org/simple/package/
  Found index url https://pypi.org/simple
  Looking up "https://pypi.org/simple/package/" in the cache
  Request header has "max_age" as 0, cache bypassed
  Starting new HTTPS connection (1): pypi.org:443
  https://pypi.org:443 "GET /simple/package/ HTTP/1.1" 404 13
  Status code 404 not in (200, 203, 300, 301)
  Could not fetch URL https://pypi.org/simple/package/: 404 Client Error: Not Found for url: https://pypi.org/simple/package/ - skipping
  Getting page https://[email protected]/pypi/package/
  Found index url https://private-repo.io/pypi
  Looking up "https://private-repo.io/pypi/package/" in the cache
  Request header has "max_age" as 0, cache bypassed
  Starting new HTTPS connection (1): private-repo.io:443
  https://private-repo.io:443 "GET /pypi/package/ HTTP/1.1" 404 10
  Status code 404 not in (200, 203, 300, 301)
  Could not fetch URL https://[email protected]/pypi/package/: 404 Client Error: Not Found for url: https://private-repo.io/pypi/package/ - skipping
  Given no hashes to check 0 links for project 'package': discarding no candidates
  ERROR: Could not find a version that satisfies the requirement package (from versions: none)
Cleaning up...
Removed build tracker '/private/var/folders/rb/rg18vqd16lxg47cm1kvgh3yh0000gn/T/pip-req-tracker-_5f9p1zv'
ERROR: No matching distribution found for package
Exception information:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 188, in main
    status = self.run(options, args)
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/commands/install.py", line 345, in run
    resolver.resolve(requirement_set)
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/legacy_resolve.py", line 196, in resolve
    self._resolve_one(requirement_set, req)
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/legacy_resolve.py", line 359, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/legacy_resolve.py", line 307, in _get_abstract_dist_for
    self.require_hashes
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/operations/prepare.py", line 134, in prepare_linked_requirement
    req.populate_link(finder, upgrade_allowed, require_hashes)
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/req/req_install.py", line 211, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "/usr/local/lib/python3.7/site-packages/pip/_internal/index.py", line 1228, in find_requirement
    'No matching distribution found for %s' % req
pip._internal.exceptions.DistributionNotFound: No matching distribution found for package

@bmckalla hast du es stattdessen mit https://:[email protected] versucht? Siehe: https://github.com/pypa/pip/issues/6775#issuecomment -514272956

@ TRTRh

Ich habe das gleiche Problem, aber ich denke, das : sollte nach dem Token gehen. Zumindest ist das eine Problemumgehung, die jetzt für mich funktioniert: https://token:@private-repo.io

@TTRh @jgspiro : nachdem der Token funktioniert hat, danke!

Für das, was es wert ist, sieht es so aus, als würden Twine-Uploads nicht funktionieren, wenn Sie einen Benutzernamen mit% 40 anstelle eines @ verwenden.

@leviable ~ Ich würde empfehlen, ein Problem im Tracker von Twine erstellen . ~ Wenn Sie Ihren ursprünglichen Beitrag genauer betrachten und einen Benutzernamen an Twine übergeben, tun Sie dies nicht als Teil einer URL, sondern als eigenständiger Wert -u <username> , sodass das Zitieren von URLs in diesem Kontext nicht funktioniert. Sie müssen den Benutzernamen zusätzlich verarbeiten, um für beide dieselbe Einstellung zu verwenden (Ideen finden Sie beispielsweise im folgenden Kommentar ).

Nur zu Ihrer Information, URL-Zitat Das Passwort funktioniert für uns.

password='passwordwith@$$!!'
encoded=$(python3 -c 'from urllib.parse import quote;print(quote("'${password}'"))')
export PIP_EXTRA_INDEX_URL='https://username:'${encoded}'@nexus.hostname.com/repository/pypi-all/simple'
pip install your_package

@ TRTRh

Ich habe das gleiche Problem, aber ich denke, das : sollte nach dem Token gehen. Zumindest ist das eine Problemumgehung, die jetzt für mich funktioniert: https://token:@private-repo.io

Wird dies als Fehler oder beabsichtigtes Verhalten angesehen (kein Speichern von Anmeldeinformationen, wenn kein : mit Token vorhanden ist)?

Einige Änderungen an download.py hier scheinen das Problem zu lösen.

Es ist ein Fehler, der meiner Meinung nach noch behoben werden muss.

Ich bin auf demselben Patch gelandet wie https://github.com/booleand/pip/commit/9761f46520b94c027b0e6732223e391088f745a5#diff -34481ab2fefef95e8820a46e86004ae7

@booleand wären Sie bereit, einen Patch einzureichen?

@pradyunsg Ja, das bin ich

@booleand es wäre toll, wenn Sie eine PR

danke @pradyunsg. reichte eine PR # 6795 ein

Nach https://github.com/pypa/pip/issues/6775#issuecomment -514284653 habe ich # 6796 für die Authentifizierung "ein Element" in der Paket-URL geöffnet.

Danke @slafs. In diesem Fall können wir diesen schließen.

Wie wäre es, diesen Fall in den Dokumenten zu dokumentieren (einschließlich eines Beispiels), da er häufig erscheint und Menschen stolpern kann?

@cjerdonek , #

Ich habe eine PR (# 6818) veröffentlicht, die unsere beiden Probleme bei der URL-Verarbeitung behebt (dies und # 6796).

Ich würde mich freuen, wenn Leute aus diesem Thread # 6818 für eine Spritztour nehmen und mich wissen lassen könnten, ob es funktioniert.

Führen Sie Folgendes aus, um pip von diesem Zweig in Ihrer lokalen Umgebung zu installieren:

pip install https://github.com/pradyunsg/pip/archive/fix/URL-authentication-handling.zip

Ich glaube nicht, dass PR dieses Problem behebt? Ich dachte, bei diesem Problem ging es um Benutzernamen, die ein @ enthalten, wenn ein Kennwort vorhanden ist (es hat nichts mit None / non-None zu tun), und bei dem anderen Problem geht es darum, dass kein Kennwort vorhanden ist. Ersteres sehe ich aber nicht unter den Testfällen. (In den Testfällen müssten zwei nicht entkappte @ -Symbole vorhanden sein.) Außerdem dachte ich, dass das Korrigieren des ersteren bedeuten würde, dass wir die URL „reparieren“ / neu schreiben müssten, was in der PR meiner Ansicht nach nicht der Fall ist.

Ersteres sehe ich nicht unter den Testfällen

Ah ja. Mein schlechtes, ich habe den Test dafür weggelassen. Ich habe diesen Fall zur Testsuite hinzugefügt. Wenn Sie ihn lokal ausführen, wird bestätigt, dass die E-Mail-Adresse korrekt extrahiert wurde.

"http://[email protected]:[email protected]/path" -> ("http://example.com/path", "[email protected]", "password")

Ich dachte, das erstere zu reparieren würde bedeuten, dass wir die URL „reparieren“ / neu schreiben müssten, was ich in der PR nicht sehe.

Ah ja. Ich auch anfangs.

Ich habe mir jedoch die verschiedenen Anfragen und urllib3-Anbieter angesehen und in einem Codepfad nichts gesehen, was uns direkt hier betroffen hätte. Ich habe mich entschlossen zu prüfen, ob die Rückkehr zu den Änderungen gegenüber der ursprünglichen Struktur funktioniert, und es scheint so, als ob dies der Fall wäre.

Nach meinem Verständnis hat dies etwas mit der Standardbehandlung von URLs zu tun, die Authentifizierungsinformationen enthalten, und (irgendwie) umgehen wir diese Probleme in unserer Unterklasse Session .

Nach meinem Verständnis hat dies etwas mit der Standardbehandlung von URLs zu tun, die Authentifizierungsinformationen enthalten, und (irgendwie) umgehen wir diese Probleme in unserer Sitzungsunterklasse.

Nein, wenn Sie sich meinen Kommentar oben ansehen, in dem ich den Traceback für dieses Problem eingefügt habe, werden Sie feststellen, dass wir die ursprüngliche URL übergeben: https://github.com/pypa/pip/issues/6775#issuecomment -514313192
Und Ihre PR "repariert" / schreibt die ursprüngliche URL nicht neu, sodass ich nicht erwarten würde, dass sich dieses Verhalten in Ihrer PR ändert.

Um sicherzugehen, habe ich diesen Befehl in Ihrer PR wiederholt und bestätigt, dass der gleiche Fehler immer noch auftritt.

Hier ist mein Kommentar oben, in dem ich über einen Ansatz zur Behebung des aktuellen Problems spreche: https://github.com/pypa/pip/issues/6775#issuecomment -514322734

Richtig, macht für mich Sinn. Ich glaube, ich habe Probleme in meinem Kopf gemischt.

Wie wäre es, diesen Fall in den Dokumenten zu dokumentieren (einschließlich eines Beispiels), da er häufig erscheint und Menschen stolpern kann?

Es wäre auch sinnvoll, in dieser Situation abzubrechen und eine Warnung auszudrucken, wenn die URL ein nicht entkoppeltes "@" enthält. Es ist wahrscheinlich besser auffindbar als die Dokumentation und freundlicher als es in der Dokumentation zu haben.

Zusammenfassung des Sachverhalts in Pip 19.2 für mein dummes Ich:

• Die Authentifizierung mit nur einem Token (dh Benutzername, kein Kennwort) ist fehlerhaft. Die aktuelle Logik von pip geht davon aus, dass beide Teile vorhanden sind. Dafür ist # 6796 da.
• Die Authentifizierung mit einem Benutzernamen, der nicht URL-codiert ist, funktioniert nicht mehr - Pip 19.2 schlägt mit einem Traceback fehl, Pip 19.1.1 akzeptiert solche URLs. Die Ursache für dieses Problem ist, dass urllib3 beim Parsen solcher URLs strenger geworden ist.

Hallo, wir haben das gleiche Problem mit pip 18.1, urllib3 (1.24.1) und Python2.7, aber im Passwortbereich.
https://pypi.org/simple --extra-index-url http://user:password@@124.4.56:8086 --trusted-host 124.4.56
https://pypi.org/project/urllib3/ listet keine Änderungen in Bezug auf die obige RFC 3986-Spezifikation auf. Auch @cjerdonek @pradyunsg können Sie bitte stabile Versionen beider Pakete empfehlen, damit wir sie lieber installieren können.

Veröffentlichtes Pip 19.2.2 mit einem Fix für die Token, die ein : benötigen.

Für Leute, die Probleme mit @ in ihren Passwörtern haben, wird empfohlen, die @ in den URLs zu umgehen.

Bearbeiten: Scheint nicht mit dem '%' zu tun zu haben, da ich mein Passwort in "Passwort" geändert habe und das gleiche Ergebnis erhalten habe.

Ein weiterer Knick: Mein altes generiertes Passwort (früher) endet mit "%".

In Version 19.2.2

Wenn Sie % durch %25 ersetzen oder in Ruhe lassen, wird der gleiche Fehler angezeigt:

(Angenommen, mein Passwort war: password% )

ERROR: Exception:
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/pip/_internal/cli/base_command.py", line 188, in main
    status = self.run(options, args)
  File "/Library/Python/2.7/site-packages/pip/_internal/commands/install.py", line 345, in run
    resolver.resolve(requirement_set)
  File "/Library/Python/2.7/site-packages/pip/_internal/legacy_resolve.py", line 196, in resolve
    self._resolve_one(requirement_set, req)
  File "/Library/Python/2.7/site-packages/pip/_internal/legacy_resolve.py", line 359, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/Library/Python/2.7/site-packages/pip/_internal/legacy_resolve.py", line 307, in _get_abstract_dist_for
    self.require_hashes
  File "/Library/Python/2.7/site-packages/pip/_internal/operations/prepare.py", line 134, in prepare_linked_requirement
    req.populate_link(finder, upgrade_allowed, require_hashes)
  File "/Library/Python/2.7/site-packages/pip/_internal/req/req_install.py", line 211, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "/Library/Python/2.7/site-packages/pip/_internal/index.py", line 1201, in find_requirement
    req.name, specifier=req.specifier, hashes=hashes,
  File "/Library/Python/2.7/site-packages/pip/_internal/index.py", line 1183, in find_candidates
    candidates = self.find_all_candidates(project_name)
  File "/Library/Python/2.7/site-packages/pip/_internal/index.py", line 1111, in find_all_candidates
    if self._validate_secure_origin(logger, link)
  File "/Library/Python/2.7/site-packages/pip/_internal/index.py", line 998, in _validate_secure_origin
    origin = (parsed.scheme, parsed.hostname, parsed.port)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urlparse.py", line 113, in port
    port = int(port, 10)
ValueError: invalid literal for int() with base 10: 'password%%40mydomain.com'

oder

ValueError: invalid literal for int() with base 10: 'password%25%40mydomain.com'

Können Sie versuchen, nur den Teil der Anmeldeinformationen der URL zu codieren - z. B. password%[email protected] ?

Wenn ich zu password%[email protected] wechsle , kann ich fortfahren.

Hier gibt es nichts Umsetzbareres. Abschließend fasse ich dieses Problem zusammen und rufe zum Handeln auf.

Was ist passiert?

Für pip 19.2 müssen Anmeldeinformationen jetzt per URL angegeben werden. Zeichen wie @ und % müssen daher per URL angegeben werden (wie %40 und %25 ).

Daher funktionieren die folgenden Index-URLs nicht mehr:

https://[email protected]:[email protected]/
https://user:password%@mydomain.com/

Die Äquivalente, die funktionieren, sind:

https://pradyunsg%40email.com:[email protected]/
https://user:password%[email protected]/

Warum?

pip (und Anfragen) verwenden urllib3 für einen Großteil der zugrunde liegenden URL-Behandlung. urllib3 hat in der Version, auf die pip in 19.2 aktualisiert wurde, eine strengere URL-Analyse eingeführt. Da diese Strenge erst nach der Veröffentlichung "aufgefangen" wurde, beschlossen die Entwickler von pip , die strengere Analyse

Wie kannst du helfen?

Die Entwickler von pip möchten die Workflows ihrer Benutzer nicht unterbrechen. Dies ist jedoch schwierig, da pip ein Projekt ist, das ausschließlich von Freiwilligen unterhalten wird und über eine alte Codebasis verfügt, die es schwierig macht, zusätzliche Mitarbeiter einzubeziehen.

Es gibt einen erheblichen Mangel an Entwicklerzeit für Pip, insbesondere angesichts der Auswirkungen, die Änderungen auf Pip haben können. Um solche Probleme zu vermeiden und wesentliche Verbesserungen an pip vorzunehmen, sollten Sie die Finanzierung von Python Packaging-Verbesserungen in Betracht ziehen. Die Finanzierung solcher Projekte im Zusammenhang mit Pip würde es den derzeitigen Betreuern ermöglichen, länger an Pip zu arbeiten, und zusätzliche Experten (UX-Experten, Projektmanager, technische Redakteure usw.) hinzuziehen, um Pip besser zu machen.