D'accord. Le comportement actuel de pip pour les liens de dépendance est vraiment nul.

4295

3610

[Écrit dans #3939, déplaçant mon commentaire ici]

Alors, voici le problème principal : si je ne veux pas utiliser un fichier requirements.txt (parce que, disons, je veux des dépendances déclaratives toutes spécifiées dans setup.cfg ), comment suis-je censé spécifier un URL comme dépendance ?

Cela ne fonctionne pas :

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

Je pense également que les liens de dépendance sont étranges et faciles à supprimer, mais canoniquement, comment ce cas d'utilisation est-il servi sinon avec ceux-ci ?

Un autre problème est que dependency_links ne peut apparemment pas être spécifié dans setup.cfg, uniquement en tant qu'arguments setup.py. S'ils ne sont plus obsolètes, cela devrait être corrigé.

Y a-t-il des nouvelles à ce sujet? Y a-t-il une alternative en cours? dependance_links_ semble être la seule option pour la distribution interne/privée des bibliothèques.

Au lieu de le déprécier, il devrait être corrigé, beaucoup de gens oublient ou deviennent confus parce qu'ils oublient de mettre à la fois le nom-version de la bibliothèque dans le install_requires et le lien de dépendance qui contient le tarbal avec l'œuf. Comme alternative, j'aimerais voir que @jleclanche a suggéré, un simple lien vers le tarball dans install_requires (spécifier l'œuf pourrait être facultatif).

Je ne pense pas que nous soyons seuls : https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

Les outils

@dstufft btw - je voudrais faire valoir que l'existence de devpi démontre une solution plus propre au problème rendant les liens de dépendance inutiles

L'héritage de l'index IMHO + liste blanche/liste noire est plus cohérent et plus compréhensible au niveau des opérations

@RonnyPfannschmidt , merci pour la suggestion, il semble qu'il me manque quelque chose d'important (les discussions sur cette dépréciation reddit :

devpi pourrait être une solution, mais introduire un autre service dans le jeu qui nécessite une maintenance et devoir attendre qu'un administrateur soit configuré, ne me permettra pas de travailler très bientôt. De plus, nous aurions toujours besoin de créer des packages, puis de les mettre sur devip (ou devpi a-t-il une fonctionnalité pour suivre les référentiels git ??)

Idéalement, j'aimerais une alternative qui ne me prendra pas plus que d'ajouter un fichier dans ma bibliothèque, ou quelques lignes dans le setup.py.

Je ne comprends fondamentalement pas la décision sous-jacente de le supprimer, je peux voir comment cela peut conduire à de mauvaises pratiques et à des insécurités, mais tant qu'il est conservé pour un usage interne, cela ne devrait pas être un problème majeur.

4175 signifie que la prise en charge de l'URL PEP 508 sera présente dans le pip 10. Je pense que cela peut être fermé.

Pensées @pfmoore @dstufft ?

Je pensais que https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d signifiait que la syntaxe @ ne pouvait pas être utilisée pour les dépendances, donc cela signifie que #4175 n'est pas une solution à ce problème . Les commentaires là-bas étaient que nous ne devrions pas implémenter la prise en charge de @ pour les dépendances jusqu'à ce que PyPI soit capable de bloquer les téléchargements qui l'ont utilisé (parce que nous ne voulons pas installer quelque chose de PyPI pour pouvoir récupérer des éléments à partir d'URL arbitraires , vraisemblablement).

Il ne devrait pas être obsolète tant qu'une alternative n'est pas en place, c'est-à-dire la prise en charge de PEP 508. Jusque-là, trop de gens l'utilisent.

Quel est le workflow approprié pour cela ?

Disons qu'il y a une bibliothèque à laquelle j'ai besoin d'ajouter une fonctionnalité. Je le fork sur Github. La fonctionnalité ne sera pas fusionnée de sitôt, j'ai donc un outil que j'ai configuré pour utiliser mon fork Github au lieu de PyPi.

Maintenant, tous mes utilisateurs doivent ajouter --process-dependency-links lors de l'installation de mon outil avec pip, qui est un indicateur obsolète et même une fois supprimé ?

Y a-t-il une option dans setup.py qui me manque ou n'y a-t-il vraiment aucun moyen de contourner cela? Il semble que le seul moyen viable de le faire soit de pousser un paquet pypi fourchu. Cela ne fera qu'ajouter à la confusion de l'utilisateur une fois que votre demande d'extraction sera fusionnée, de toute façon.

Venons en à cela.

--process-dependency-links n'a pas vraiment d'alternative aujourd'hui. Donc, je suggère que nous allions de l'avant et que nous le dépréciions.

Cependant, le drapeau signifie que pip atteindrait des URL arbitraires - il devrait y avoir un avertissement à ce sujet.

@pradyunsg à moins qu'il n'y ait un plan réel pour le tuer pour de bon, je suggère fortement de laisser ce zombie se reposer ou d'être supprimé

Je ne pense pas que les personnes qui en ont réellement besoin soient incitées à régler la situation à moins que pip ne dise "NON, je ne prends pas votre dette"

En tant que mainteneur de pip, mon souci est de ne pas permettre à pip d'être un vecteur d'exploits. Pip suppose PyPI comme index par défaut, il y a donc une confiance implicite dans PyPI. Alors mes premières questions sont :

1. Existe-t-il sur PyPI des packages contenant des métadonnées dependency_links ?
2. PyPI pourrait-il être modifié pour refuser le téléchargement de projets avec dependency_links (ou le fait-il déjà) ?
3. Alternativement, pip pourrait-il simplement refuser de traiter les liens de dépendance (indépendamment du fait que l'option soit définie) pour les packages téléchargés à partir de PyPI ?

Si nous pouvions être sûrs qu'il n'y avait aucun moyen pour les utilisateurs de pip d'être mordus par des packages sur PyPI avec des dependency_links malveillants, je serais moins inquiet. Les utilisateurs qui choisissent d'utiliser un index personnalisé doivent décider eux-mêmes s'ils doivent lui faire confiance. (Je préférerais toujours conserver le drapeau même alors - il s'agit potentiellement d'un exploit à distance et devrait toujours être explicitement activé).

Donc, avec les changements suivants :

1. Pip ne traitera jamais les liens de dépendance de PyPI (soit explicitement, soit simplement parce que nous savons qu'ils ne sont pas là)
2. L'indicateur --process-dependency-links n'est pas obsolète, mais ne fonctionne que pour les index personnalisés.

Je serais d'accord pour accepter cela comme le statu quo. Les personnes ayant besoin d'une fonctionnalité de style de lien de dépendance peuvent alors se demander comment (le cas échéant) elles veulent aller de l'avant.

Si quelqu'un le voulait, nous pourrions mettre tout cela dans une métadonnée de lien de dépendance définissant une norme, et la dépréciation actuelle deviendrait alors "le comportement actuel sera abandonné en faveur du comportement spécifié dans la norme". Mais d'un point de vue centré sur le pip, je préfère simplement le faire - laisser les personnes qui ont besoin de liens de dépendance se charger du travail de normalisation (c'est dans leur intérêt après tout, car elles ont alors un itinéraire - obtenir un changement standard - à modifier le comportement de pip avec le plein consensus de la communauté).

Fondamentalement, nous avons une fonctionnalité destinée à remplacer les liens de dépendance, mais pip n'a pas encore commencé à la respecter, car nous n'avons pas encore de moyen de bloquer les téléchargements vers PyPI qui l'utilisent.

Vous voulez dire #4175 ? Lequel est bloqué à cause de 86b0779 ? Peut-être pourrions-nous modifier https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 pour ne donner l'erreur que si comes_from est PyPI ?

Ensuite, nous pourrions changer l'avertissement d'obsolescence pour --process-dependency-links pour dire que les utilisateurs doivent passer à la syntaxe @ , et supprimer --process-dependency-links après une période d'obsolescence raisonnable (nous devrions commencer le compte à rebours à partir du moment où la syntaxe @ devient disponible).

@pfmoore Oui, c'est exactement ça, et cela semble être une voie à suivre possible.

D'ACCORD. Si personne d'autre n'y parvient en premier, je m'occuperai d'écrire un PR.

D'après ce que je comprends, le problème de l'utilisateur ici est qu'il doit transmettre une option qui dit explicitement "hé, je suis obsolète" lorsque vous la transmettez pour une fonctionnalité qui n'a pas d'alternative.

Je suis en faveur de l'abandon complet du support dedependent_links pendant une période d'obsolescence. Et dans le même temps, l'ajout de la prise en charge des dépendances URL PEP 508, dont je pense que pip devrait toujours être bruyant lorsqu'il est utilisé et qu'ils devraient toujours être activés.

Cela voudrait dire :

• mettre la capacité de traiter PEP 508 url-deps derrière un drapeau
  
  
  
  • à part : devrait nommer le drapeau de manière à ce qu'un utilisateur concerné par la sécurité vérifie les documents
  
  
• commencer à refuser d'installer PEP 508 url-deps lorsqu'ils proviennent d'un package PyPI
• les liens de dépendance restent obsolètes mais nous avons une date pour les supprimer
  
  
  
  • Honnêtement, je ne veux pas donner à cela une période de dépréciation plus longue qu'une seule version imprimant l'alternative.
  
  

Je l'ai tapé hier mais je ne l'ai pas envoyé. Je me rends compte maintenant que c'est fondamentalement la même chose que le dernier commentaire de @pfmoore .

_Yay!

Les services d'URL devraient-ils exiger un indicateur d'activation ? Le PEP 508 ne le dit pas, et la mise en œuvre actuelle ne le fait pas. Je peux voir la logique, mais je ne fais pas confiance à mon jugement sur les questions de sécurité par rapport à la facilité d'utilisation.

De plus, j'aimerais voir une documentation claire sur la façon dont les projets doivent passer des liens de dépendance à la syntaxe @ avant de commencer à pousser le commutateur. Il est déjà assez difficile d'atteindre les personnes qui seront affectées par les dépréciations, et les avertissements selon lesquels elles ne peuvent pas trouver la solution ne seront d'aucune utilité. Idéalement, l'avertissement devrait inclure un pointeur vers un document « comment changer », IMO.

Je ne fais pas confiance à mon jugement sur les questions de sécurité par rapport à la facilité d'utilisation.

Je suis enclin à : "être sécurisé par défaut" et à opter pour un comportement moins sécurisé.

une documentation claire sur la façon dont les projets doivent passer des liens de dépendance à la syntaxe @ avant de commencer à pousser le commutateur

Cela me semble bien.

Je suis enclin à : "être sécurisé par défaut" et à opter pour un comportement moins sécurisé.

En tant que personne qui s'obstine à gérer les contraintes de pare-feu et de sécurité dans mon travail, je suis très conscient que nous n'avons pas beaucoup de compréhension du type d'environnements où cette fonctionnalité est susceptible d'être la plus utile (développement interne, code source fermé , des flux de travail et des dispositions de réseau étroitement contrôlés, etc.). Donc, mon inclination est d'être sécurisé pour le flux de travail par défaut (PyPI) mais de ne pas mettre des obstacles supplémentaires sur le chemin des personnes avec des cas d'utilisation qui sont clairement importants pour leur flux de travail, mais où nous ne comprenons pas correctement les compromis qu'ils doivent faire Fabriquer.

À mon avis, « si le package provient d'un serveur que vous avez explicitement choisi d'utiliser » est suffisant pour autoriser les liens URL.

Voir? Ce n'est pas que je n'ai pas d' opinion, juste que je ne suis pas sûr que mes préjugés ne soient pas visibles :sourire:

ne pas mettre des obstacles supplémentaires sur le chemin des personnes avec des cas d'utilisation qui sont clairement importants pour leur flux de travail, mais où nous ne comprenons pas correctement les compromis qu'ils doivent faire.

Assez juste. Si certains utilisateurs pouvaient fournir des informations sur leur flux de travail, ce serait bien.

« si le package provient d'un serveur que vous avez explicitement choisi d'utiliser » est suffisant pour autoriser les liens URL.

Je ne suis pas sûr ici. :/

Voir? Ce n'est pas que je n'ai pas d'opinion, juste que je ne suis pas sûr que mes préjugés ne se voient pas

Héhé.

Assez juste. Si certains utilisateurs pouvaient fournir des informations sur leur flux de travail, ce serait bien.

À mon avis, « si le package provient d'un serveur que vous avez explicitement choisi d'utiliser » est suffisant pour autoriser les liens URL.

Le simple fait d'autoriser les sources de GitHub résoudrait 99% du problème pour moi. Les packages en amont ont des bogues ou des fonctionnalités manquantes. Je les bifurque et les répare, émets un PR, puis attends peut-être très longtemps pour les fusionner, puis les publier sur PyPI. En attendant, mes packages reposent sur les correctifs de ces packages.

Cela peut être opt-in, tant que cela peut être fait en une seule ligne.

Ce n'est pas vraiment un problème de sécurité d'utiliser des liens directs (en supposant que HTTPS/etc), c'est juste un problème de disponibilité. Étant donné que nous les interdisons à partir de PyPI, je dirais que c'est assez bon et que nous n'avons pas besoin d'un autre indicateur.

Dans mon travail, nous tomberions dans certains des cas d' @pfmoore , à savoir le développement interne avant qu'un package ne soit open source, source fermée, etc. (toujours des packages internes dépendant d'autres packages internes, tous dans un serveur de contrôle de version ).
Cependant, je vois aussi le cas d'utilisation possible de quelqu'un faisant référence à un emplacement de système de fichiers...
Serait-il judicieux de fournir une liste d'hôtes/d'emplacements sur liste blanche ? Comme l'a suggéré --whitelisted-host ?

@masdeseiscaracteres Je pense que vous avez peut-être mal compris - je suggérais que si un package était récupéré à partir de PyPI, nous échouerions si l'une de ses dépendances était spécifiée via une référence @ . Mais de toute façon, il ne devrait pas y avoir de tels cas sur PyPI (nous prévoyons de les rejeter à un moment donné, nous n'avons tout simplement pas encore été en mesure de les configurer). Toutes les autres utilisations des références @ seraient acceptables.

On dirait que nous allons aller de l'avant avec un PR qui fait ce qui est décrit par @pfmoore dans https://github.com/pypa/pip/issues/4187#issuecomment -389846189.

PR bienvenus. :)

Notez que je n'ai pas eu le temps d'y arriver - non pas parce que le changement est difficile (comme indiqué, il semble être simplement un chèque contre comes_from ) mais plutôt parce que je ne sais pas comment provoquer le erreur moi-même (et plus important, je ne sais pas comment écrire un test qui le fait). Si quelqu'un peut fournir un exemple d'un tel cas de test, ce serait extrêmement utile.

Si quelqu'un peut fournir un exemple d'un tel cas de test, ce serait extrêmement utile.

Il existe un test test_install_pep508_with_url_in_install_requires qui le démontre.

En ce qui concerne les erreurs lors de l'installation à partir de PyPI, je ne vois pas de meilleure option que de télécharger quelque chose sur PyPI qui a une exigence d'URL. 😞 J'ai téléchargé un package sur PyPI à cet effet. https://pypi.org/project/pep-508-url-deps/

Une autre chose est -- comes_from n'est pas une URL ou un chemin, c'est une chaîne le long des lignes de 'box==0.1.0 from file:///private/tmp/box' . Quiconque cherche à résoudre ce problème doit maintenant trouver un meilleur moyen d'éliminer les erreurs, afin que nous ayons des informations sur l'origine d'un package. :)

@pfmoore ce problème me tient à cœur 😄 Le téléchargement de

@bstrdsmkr Non, et comme le dit @pradyunsg , ce n'est pas aussi simple que je le pensais, car comes_from n'est pas l'URL source. Je ne sais donc pas quand j'aurai le temps maintenant (je n'ai pas d'utilisation personnelle de cette fonctionnalité, elle n'est donc pas en haut de ma liste de priorités).

Comme indiqué ci-dessus, les PR sont les bienvenus :-)

J'ajouterai que le package téléchargé n'aide en aucune manière à la mise en œuvre, il n'est utile que pour tester la fonctionnalité.

D'après ce que je comprends, le correctif souhaité est quelque chose comme :

if req.url and is_like(req.url, PYPI.url):
    raise

dans https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
où is_like() renvoie True si l'URL est racine sur le même domaine. Est-ce exact?

Ouais. Je le pense. Ce sera le changement de code.

Et, nous aurons besoin d'ajouter/mettre à jour des tests et une entrée NEWS.

Je pense également que ce changement est suffisamment important pour justifier une chance le message de dépréciation fournissant un lien vers la documentation + une section supplémentaire dans le guide de l'utilisateur indiquant aux gens comment passer à l'alternative.

En tant que mainteneur de pip, mon souci est de ne pas permettre à pip d'être un vecteur d'exploits. Pip suppose PyPI comme index par défaut, il y a donc une confiance implicite dans PyPI.

Non, il y a une confiance explicite. Et l'ajout de protections contre l'utilisation de sources externes dans les dépendances IMHO n'améliorera pas la situation : il est plus pratique de masquer les logiciels malveillants dans pypi que dans un VCS accessible au public.

À mon humble avis, une meilleure approche consisterait à utiliser les VCS du développeur comme sources principales et à conserver pypy comme registre pointant vers eux et un proxy de mise en cache avec une preuve cryptographique solide que le contenu de VCS est identique à celui obtenu à partir de pypy. je veux dire

0 inscription

dev -- public key --> pypa

1 téléchargement

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 au ralenti :

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 récupération

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 les sources installées correspondent à celles du VCS à cause de la signature
2 l'auteur correspond aussi
3 pypa peut tricher avec de nouveaux utilisateurs, mais la tricherie peut être détectée par les anciens
4 L'auteur peut tricher en affichant dans une branche d'interface Web autre que celle donnée à pypy et en envoyant à pypy une autre branche. Cela ne fonctionnera pas bien si nous faisons de la branche une partie obligatoire de l'URI.

@KOLANICH Je pense que vous voulez dire PyPI (Python Packaging Index) quand vous dites pypy/pypa. PyPy est une implémentation alternative de Python. PyPA (Python Packaging Authority) est un groupe de bénévoles qui maintiennent des projets majeurs dans l'espace Python Packaging. S'il vous plaît, corrigez les acronymes ou évitez de les utiliser.

Vous proposez de modifier fondamentalement la conception d'un service existant bien établi. Si vous souhaitez avoir de tels changements majeurs, vous êtes invités à fournir au moins un plan de transition (faisable) et une implémentation POC, pour gérer/modifier l'architecture afin de permettre la transition/minimiser la rupture des workflows existants. Notez que dépendre de l'hébergement externe est quelque chose qui a été explicitement supprimé de PyPI dans le passé dans PEP 470 , mais c'était un cas assez différent de ce que vous suggérez.

PyPI est maintenu par des bénévoles, fonctionnant sur une infrastructure donnée/parrainée. Vous suggérez qu'il se connecte via Tor, un autre service géré/géré par des bénévoles. Ces deux projets sont majeurs et ils ont un coût associé à leur fonctionnement, même s'il n'est pas directement supporté/visible pour ses utilisateurs.

Néanmoins, ce n'est pas le bon endroit pour cette discussion. Si vous souhaitez proposer une refonte de PyPI, je vous suggère de démarrer une discussion sur https://github.com/pypa/warehouse.

Merci pour les suggestions.

Voir #5571 -- le PR pour cela pour savoir pourquoi cela a été poussé vers une version ultérieure.

L'avertissement dans le journal d'installation de PIP donne cette URL, mais il n'y a pas de solution au problème ni ici ni dans les autres tickets mentionnés.

De plus, c'est encore plus déroutant : qu'entendez-vous par PyPI ? Voulez-vous dire n'importe quel serveur qui implémente l'interface PyPI (par exemple Artifactory), ou, plus précisément, pypi.org ?

Maintenant, évidemment, quelqu'un qui veut prendre en charge à la fois l'installation d'un paquet via setuptools (aka en exécutant setup.py install ) et en utilisant pip install sera maintenant dans un cornichon. La spécification de liens de dépendance est le seul moyen pour une personne dans cette situation de gérer plusieurs packages interdépendants.

Maintenant, corrigez-moi si je me trompe, mais jusqu'à présent, il semble que si vous retirez cela en fonction de la décision prise par PyPA concernant les téléchargements sur leurs serveurs, vous rendez essentiellement pip inutile pour les utilisateurs d'Artifactory / les entreprises qui ont des référentiels privés avec des packages interdépendants.

S'il vous plaît, dites-moi que je me trompe et que j'ai raté quelque chose dans toute cette histoire (je la suivais par intermittence pendant un moment). J'ai rouge PEP 508, mais cela ne fait vraiment aucune différence à cet égard, du moins, je ne vois pas en quoi cela rendrait les choses meilleures ou pires.

@wvxvw-traiana Je pense que tu as raté le PR #5571
Avant ce PR (et dans la version actuelle - 18.0), pip refusera d'installer toute dépendance spécifiée via la syntaxe PEP508.

Après ce PR (déjà fusionné donc devrait être dans 18.1+), pip ne refusera de telles dépendances que si le paquet qui en dépend provient de pypi.org.

Si vous installez un package à partir de votre dépôt privé qui dépend de choses de pypi, c'est évidemment très bien.
Si vous installez un package à partir de pypi.org qui dépend des éléments de votre référentiel privé, cela échoue.
Si vous installez un package à partir de votre référentiel privé qui dépend des éléments de votre référentiel privé, ce n'est pas un problème.

J'espère que cela aidera à clarifier les choses

@bstrdsmkr Est-ce la même origine ou pypi est-il un cas particulier ? C'est à dire

Si vous installez un package à partir de votre dépôt privé qui dépend d'éléments d'un autre dépôt privé.

Pour ajouter un peu plus de contexte sur les raisons derrière cela :

1. Les liens URL directs permettent à un package de déclencher le téléchargement et l'exécution de code arbitraire depuis n'importe où sur Internet. Ce n'est pas grave si vous assumez la responsabilité du package en le faisant, nous autorisons donc les liens URL directs sur cette compréhension.
2. Les gens s'attendent à installer à partir de PyPI (en particulier PyPI, pas les index de packages en général) et font confiance aux packages qu'ils téléchargent à partir de là. Pour éviter une compromission d'un package PyPI exposant un grand nombre d'utilisateurs Python, nous n'autorisons pas les packages provenant de PyPI à dépendre de liens URL directs (car cela impose trop de fardeau à nos utilisateurs pour insister sur le fait qu'ils doivent tout auditer de PyPI qu'ils utilisent pour les liens vers du code externe).
3. Les liens de dépendance sont un mécanisme spécifique à setuptools et sont traités par la machinerie interne de setuptools, pas par pip. Ainsi, contrairement aux liens URL directs, nous n'avons aucun contrôle sur ce qu'ils font. C'est pourquoi nous les avons déconseillées au profit de la forme URL directe standard, que nous gérons nous-mêmes.

quelqu'un qui souhaite prendre en charge à la fois l'installation d'un package via setuptools (c'est-à-dire l'exécution de setup.py install) et l'utilisation de pip install sera désormais dans le pétrin.

Si c'est vrai, c'est parce que setuptools n'a pas implémenté la prise en charge des liens URL directs, ce qui est une norme convenue. N'hésitez pas à en parler avec eux.

Si vous installez un package à partir de votre dépôt privé qui dépend d'éléments d'un autre dépôt privé.

Cela fonctionne bien. PyPI n'est pas impliqué.

OK, donc, d'un côté, je suis content que cela ne m'affecte pas.

D'un autre côté, ce "correctif" semble, comment l'ai-je dit... trop facile à contourner.

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

Ce n'est pas mon affaire, vraiment, mais cela semble être une approche vraiment superficielle. (L'autre vecteur d'attaque a été mentionné dans d'autres commentaires, où vous pouvez simplement télécharger ce que vous voulez dans setup.py).

Il n'est pas conçu pour être difficile pour les utilisateurs de travailler autour de par les utilisateurs. C'est un moyen d'offrir une solution (limitée) au fait que PyPI n'a pas encore de moyen d'empêcher les gens de télécharger des packages avec des dépendances URL directes. Voir https://github.com/pypa/pip/pull/4175#issuecomment -266305694 pour un certain contexte.

@dpwrussell pypi.org est un cas particulier. N'importe quel dépôt privé vers n'importe quel dépôt privé fonctionne correctement après le changement.

@wvxvw-traiana, cela ne vise pas à vous empêcher de le faire vous-même. Il est destiné à empêcher quelqu'un d'autre de vous faire cela lorsque vous pensez que vous installez simplement un package à partir de pypi.org

Sans rapport avec la discussion actuelle, je rouvre ceci car nous n'avons pas réellement mis à jour l'avertissement de dépréciation pour cela.

5726 ajoute un langage suggérant l'utilisation des URL PEP 508, dont l'IMO est le dernier bit nécessaire pour cela.

D'accord alors. Permettez-moi de résumer :

• les liens de dépendance sont toujours obsolètes et doivent maintenant être supprimés dans le pip 19.0.
• remplacement standard car il s'agit de dépendances d'URL PEP 508
• Lors de l'installation à partir de PyPI, si un package a des dépendances URL PEP 508, cela entraînera l'abandon de l'installation par pip.

@pfmoore a détaillé les raisons de ces décisions ici : https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg Quand les dépendances d'URL PEP 508 seront-elles autorisées dans install_requires dans setup.py ? Y a-t-il une date fixée?

Dans la prochaine version de pip -- c'est 18.1, prévue pour octobre. Vous pouvez en savoir plus sur le cycle de publication de 3 mois de pip sur https://pip.pypa.io/en/latest/development/release-process/. :)

https://github.com/pypa/wheel/issues/249 doit être traité avant que les dépendances d'URL PEP 508 ne deviennent une alternative viable.

pypa/wheel#249 doit être résolu avant que les dépendances URL PEP 508 ne deviennent une alternative viable.

Cela a été résolu.

Dans les notes de version de pip 18.1, il est dit

Autoriser l'utilisation des exigences d'URL PEP 508 en tant que dépendances.

Par mesure de sécurité, pip lèvera une exception lors de l'installation de packages à partir de PyPI si ces packages dépendent de packages qui ne sont pas également hébergés sur PyPI. À l'avenir, PyPI bloquera directement le téléchargement de packages avec de telles dépendances d'URL externes. (#4187)

Cela signifie donc essentiellement que les dépendances peuvent être spécifiées à l'aide d'URL, mais si ce ne sont pas des URL PyPI, le package ne peut pas être installé à l'aide de pip ? Peut-être que je me trompe complètement, mais comment les dépendances d'URL sont-elles censées être utilisées alors ?

Les packages

Les packages qui ne sont PAS hébergés chez PyPI peuvent avoir des dépendances d'URL. Si vous installez le package directement depuis github (par exemple), les dépendances d'URL seront résolues et installées. Un exemple d'une telle installation :

pip install git+https://github.com/bstrdsmkr/some_package.git

Essentiellement, si vous installez à partir d'une URL, cela peut dépendre des URL, sinon ce n'est pas le cas. Et juste pour plus de clarté, il peut également avoir des dépendances URL et non-url

Un petit ajout :

...si vous installez à partir d'une URL, cela peut dépendre des URL

...si vous installez à partir d'une URL (VCS ou autre) ou d'un fichier local ou d'un index de package qui n'est pas PyPI, cela peut...

Existe-t-il donc une version de pip qui traite install_requires conformément aux descriptions ci-dessus ? Je ne peux pas déterminer les balises au-dessus de l'état final et la documentation pip actuelle pointe vers la documentation install_requires dans setuptools qui dit toujours d'utiliser dependency_links .

Je ne peux pas parler moi-même à la documentation, mais cette "assouplissement" pour permettre aux packages non-PyPI d'installer des dépendances à partir d'URL a été publiée dans pip 18.0

AFAIK, les dépendances d'URL dans install_requires sont prises en charge depuis le pip 18.1 :

Autoriser l'utilisation des exigences d'URL PEP 508 en tant que dépendances.

Source : notes de version

Ugh, faute de frappe de ma part -- @pietrodn est évidemment correct

Je veux laisser un exemple petit mais réussi ici pour ceux qui sont tombés sur ce problème pour la première fois terrifiés (comme moi) à propos de ce qu'il faut faire sans --process-dependency-links. En utilisant ce workflow, mes utilisateurs peuvent désormais effectuer une installation pip depuis GitHub ou depuis des sources locales (pas PyPI), ou pip install requirements.txt, ou python setup.py install, et travailler sur Travis-CI, avec pip version 18+, donc je pense qu'elle couvre beaucoup de bases. J'espère que cela sera utile à quelqu'un, et toutes mes excuses si cela semble hors sujet à d'autres :

Dans votre fichier requirements.txt, en supposant que vous vouliez que les gens puissent dépendre de la branche dev GitHub du package "foo", par exemple :

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

Dans votre fichier setup.py :

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

Certains diront que confondre install_requires et requirements.txt est mal avisé, et pour une version publiée, je suis d'accord, mais je pense que cela fonctionne bien pour le développement.

Ah, chouette. Donc, si disons que les packages "A" et "B" utilisent tous les deux cette méthode et que le package "A" répertorie "B" en tant que dépendance, lorsque vous installez "A", il finit en fait par traiter le fichier requirements.txt pour "B" (ce qui n'est pas le cas normalement) - n'est-ce pas ?

J'ai également lu ce matin que install_requires lui-même était un peu mauvais car ces installations ont été effectuées par setuptools, ce qui signifie que toutes les options de pip ont été ignorées, mais je ne sais pas si cette information est obsolète ...

J'ai également lu ce matin que install_requires lui-même était un peu mauvais car ces installations ont été effectuées par setuptools, ce qui signifie que toutes les options de pip ont été ignorées, mais je ne sais pas si cette information est obsolète ...

Vous confondez install_requires avec setup_requires .

Ah, chouette. Donc, si disons que les packages "A" et "B" utilisent tous les deux cette méthode et que le package "A" répertorie "B" en tant que dépendance, lorsque vous installez "A", il finit en fait par traiter le fichier requirements.txt pour "B" (ce qui n'est pas le cas normalement) - n'est-ce pas ?

@stevebrasier Oui, je pense que ce serait le cas, ce qui pourrait être un problème si vous avez épinglé différentes versions d'autres packages requis dans A que dans B.

Salut les gars, j'aime juste noter que le chemin de dépréciation dans ce cas était beaucoup trop court. Je sais que les liens de dépendance sont marqués comme obsolètes depuis un certain temps, mais les URL PEP 508, qui peuvent être utilisées pour les remplacer, n'ont été implémentées que le 18.1. En conséquence, il n'y avait qu'une fenêtre de 3 mois pour passer des liens de dépendance aux exigences d'URL, ce qui est très court pour les grands projets.

@rgerkin Salut, j'essaye de suivre tes instructions en vain,

Recherche de PACKAGE@ git+ ssh://[email protected] : git@BRANCHE
Lecture https://pypi.org/simple/PACKAGE/
Impossible de trouver la page d'index pour « PACKAGE » (peut-être mal orthographié ?)
Index d'analyse de tous les packages (cela peut prendre un certain temps)
Lecture https://pypi.org/simple/

PACKAGE@ git+ ssh://[email protected] : git@BRANCH , c'est dans install_requires.

Auriez-vous une idée de pourquoi je reçois ce qui précède?

@KevinMars Il existe quelques différences entre mon exemple et ce que vous avez, notamment l'utilisation de git_ssh, bitbucket, un suffixe a.git, une branche nommée et aucune balise de version. Peut-être qu'une ou plusieurs de ces choses amènent pip à rechercher sur PyPI plutôt que sur votre URL. Quelle version de pip utilisez-vous ?

Pour remarquer quelque chose que j'ai trouvé : L'utilisation de setup.py pour installer le package avec python setup.py install nécessite toujours des déclarations de dépendances externes dans dependency_links .

Dans votre fichier setup.py :

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin Merci d'avoir partagé cette solution. Mais que se passe-t-il si j'utilise pbr pour configurer mon package Python ? Comment adapter cela pour s'adapter à pbr?

@KevinMars J'ai

Je viens de réaliser que --process-dependency-links n'existait plus. Je suis reconnaissant pour tout le travail que fait la communauté. Essayer de justifier la décision par des discussions sans fin et un labyrinthe de fermetures de problèmes et de redirection était la solution choisie, mais je pense toujours que laisser cette option n'aurait nui à personne.