Hmm, nous avons peut-être besoin d'une commande pour répertorier toutes les versions de packages disponibles dans PyPI.
Ce que vous pensez?

Comme:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

J'aime cette idée.

Original Comment By: CarlFK

Je viens de l'implémenter dans mon fork. Je veux les avis de carljm, jezdez et ianb
avant de fusionner.

Vérifiez-le ici : https://bitbucket.org/hltbra/pip-list-
commande/changeset/e5c135a46204

Original Comment By: Hugo Lopes Tavares

Je n'y ai pas beaucoup réfléchi, mais il me semble préférable d'améliorer le
Commande "search" pour également lister les versions (peut-être lister toutes les versions avec un indicateur -v
ou quelque chose), plutôt que d'ajouter une nouvelle commande séparée. Cette fonctionnalité
semble faire logiquement partie de la recherche.

Original Comment By: Carl Meyer

Je serais d'accord pour ajouter ceci à la recherche tant que mon autre ER est implémenté
aussi pour ne pas avoir 3000 lignes (vraiment) quand je cherche les versions de django.
(il y a plus de 1000 accès à "pip search django" à cause de tous les django-foo
paquets. )

Original Comment By: CarlFK

Je pense qu'il est inutile de montrer quelle version serait installée tant que
il y a une liste des versions disponibles, car il est facile de déterminer laquelle de
c'est le dernier. De plus, il n'y a aucune raison d'utiliser un nouveau drapeau pour
activer la sortie de cette liste, car la surcharge tend vers zéro. C'est
juste un petit changement :
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

Salut Carl, j'ai pensé à ajouter une option à la commande de recherche, mais ma peur
s'est-il passé ce qui est arrivé à la commande d'installation : si vous souhaitez "mettre à niveau" un
package, vous devez utiliser l'option "installer" - c'est bizarre, et nous le savons.

Et si la plupart des gens pensent que c'est mieux d'ajouter une option de recherche, je ne vois pas trop
beaucoup de problèmes pour utiliser search --versions ou search -v.

Original Comment By: Hugo Lopes Tavares

Je pense que lister toutes les versions disponibles par défaut est trop verbeux. Quelque
les packages ont de nombreuses versions disponibles sur pypi - dix ou vingt n'est pas rare
du tout. Répertorier la dernière version par défaut et toutes les versions avec un indicateur
semble raisonnable.

Et je suis d'accord avec CarlFK que nous avons également besoin d'améliorations pour la recherche
plus facile à rétrécir. Le problème, c'est que nous dépendons de ce que l'API de PyPI nous donne,
ce qui n'est pas beaucoup : nous n'allons pas télécharger tout PyPI et faire une regex
chercher localement ! Je serais en faveur de quelque chose comme un drapeau --exact pour rechercher comme
partie de ce changement, vous pouvez donc rechercher par exemple "--exact django" et n'obtenir que
django lui-même dans votre résultat.

Original Comment By: Carl Meyer

Salut jumpa, Excellente idée de montrer les versions en utilisant celle obtenue de xmlrpc
connexion!

J'ai obtenu le snip suivant à la recherche de pip:

pip                       - pip installs packages.  Python packages.  An

remplacement easy_install (versions : 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2)

Cela va être une si grande liste de packages, utilisant de nombreuses versions -
parce que notre recherche se soucie des noms et des résumés. Doit-on s'en soucier ?

Original Comment By: Hugo Lopes Tavares

En tant qu'utilisateur final, j'aime l'idée d'avoir une commande de liste séparée*. Comme le temps
va sur une commande distincte peut-être plus facile à modifier et à améliorer isolément. Pour
rendre une commande de liste séparée plus utile, vous pouvez indiquer quelle version, si
any, est actuellement installé.

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

Remarque : de nombreux gestionnaires de packages populaires tels que YUM (RedHat), pkglist (BSD),
dpkg(Debain) fournit un indicateur ou une commande de liste distincte.

Original Comment By: Kelsey Hightower

Carl, je réfléchissais un autre jour à cette question, et je suis d'accord avec
Kelsey : une autre commande n'est pas mauvaise.

Imaginez que nous utilisions un drapeau pour indiquer que je veux juste ce nom de package, et
un autre drapeau pour indiquer que je veux récupérer toutes les versions disponibles.

C'est un peu bizarre.

Essayons d'illustrer :

$ pip search -v --exact Django

contre

$ pip list Django

L'idée de Kelsey de montrer quelle version est installée améliore simplement la liste
commander.

Original Comment By: Hugo Lopes Tavares

J'ai fait les changements dans la commande de recherche.

Étant donné que la commande de recherche affiche déjà la version installée et la dernière version disponible, il est probablement plus logique d'augmenter la commande de recherche pour répertorier également toutes les versions disponibles.

Voici mon ensemble de modifications : https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

Où en est-on ? Peut-on voir la dernière version disponible sur PyPI en utilisant pip ?

Est-ce déjà implémenté ? Cela me harcèle depuis environ deux ans maintenant, et j'aimerais voir cela résolu.
La recherche limitée combinée à un drapeau pour les versions ressemble à une solution très utilisable.

Je voulais juste ajouter ici que je viens de parcourir ce fil tout en cherchant comment afficher les versions ... J'ai essayé pip search -v package - d'une manière ou d'une autre, cela aurait eu un sens intuitif pour moi: une description détaillée du paquet à être installé, y compris les informations de version...

J'ai _juste_ réalisé que cette fonctionnalité n'était toujours pas implémentée après qu'un de mes collègues m'en ait parlé. Y a-t-il des plans pour qu'il devienne disponible dans les prochaines versions de pip ?

Je pense que ce PR pourrait être pertinent, c'est actuellement en cours d'élaboration ?

Vous pourriez également être intéressé par la conférence Linuxconf 2014 "Python Packaging 2.0: Playing Well With Others" sur la situation actuelle, ainsi que l'avenir, de l'emballage python. L'orateur a dit (si j'ai bien compris) que certaines des limitations sur les métadonnées dans pip sont une conséquence de la conception de PyPI, qui était à l'origine basée sur CPAN, et que retravailler le backend de PyPI (tout en restant compatible avec l'actuel en utilisant des tests) devrait améliorer la situation. Il parlait principalement des "intégrateurs de systèmes", c'est-à-dire des conditionneurs en aval, mais je suppose que cela affecterait des choses comme ce problème, les rendant plus faciles à résoudre.

+1 000 000

et comment ça va maintenant?

Maintenant, existe-t-il un moyen de montrer quelle version est la plus récente sans l'installer ?
Ce problème est ouvert depuis 2011 et le patch que j'ai vu ci-dessus n'est qu'une ligne. :(

Cela semble être une fonctionnalité mineure à activer, comment n'y a-t-il pas une option équivalente à dire apt-cache madison à ce stade ?

J'aimerais vraiment voir la dernière version du package PyPi lors de la recherche également. Avoir une correspondance exacte fonctionne, mais j'utilise awk comme solution de contournement.

Cela m'a également frustré et voyant qu'il y avait peu ou pas d'espoir là-dessus, j'ai décidé que la création d'une alternative pourrait valoir la peine. Parallèlement à ce problème, j'ai implémenté d'autres fonctionnalités demandées (comme la recherche de regex et la sortie colorisée, etc.). Si vous êtes intéressé, vous pouvez le consulter ici

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | trier -u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif Cela ne trouvera pas toujours la bonne version (pip ignore les alphas, les bêtas, les release candidates, etc. sauf si --pre est fourni). C'est plus proche (mais sans garantie non plus):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

Ok, alors la réponse JSON devrait inclure quelque chose comme "pre-version": "1.2.3a4" , donc on peut les grep tous les deux avec une expression simple.

Je ne comprends pas vraiment ce problème... De quoi s'agit-il ?

• Ajouter une nouvelle option sur pip install qui ferait que pip ne fonctionnerait que jusqu'à la résolution des packages et imprimerait les packages sélectionnés et quitterait (en sautant l'installation) ?
• Affichage de la dernière version à côté des noms de packages lors de l'utilisation pip search ?
  
  
  
  • Pouvoir voir la dernière version d'un paquet sur PyPI ?
  
  

Ce dernier me semble avoir été résolu et le premier devrait probablement recevoir un nouveau problème dédié.

@pradyunsg Eh bien, si je me souviens bien, j'avais besoin d'un moyen simple de vérifier quelle version est actuellement disponible (version et pré-version). Cette version sera installée par pip install -U [--pre] .

J'en avais besoin pour un script mettant en place un virtualenv. Lorsqu'il y avait une version plus récente d'un paquet, il demandait s'il fallait mettre à jour ou conserver la version actuelle. Ce cas d'utilisation est donc couvert par la nouvelle recherche pip.

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Publier --download -version obsolète...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Utiliser quelque chose comme :

pip install foo==

donne une liste de toutes les versions disponibles (pour un package pypi disponible valide, molécule dans ce cas):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

mais ce serait bien de pouvoir obtenir la version qui serait installée à l'aide de pip sans la télécharger et/ou l'installer sur dev/null :-)

D'accord. Un gestionnaire de paquets sans cette fonctionnalité est une sorte de blague. Même votre exemple d'obtention d'une liste de versions est un hack complet pour compenser une autre fonctionnalité que ce gestionnaire de packages n'a pas. Je ne dis pas cela pour être méchant, mais ce sont des choses qui auraient dû être disponibles bien avant il y a huit ans, lorsque ce bogue qui est totalement ignoré a été créé. Je suppose que pip sera simplement remplacé par quelque chose qui a en fait plus de fonctionnalités, mais qui est aussi abominablement, grotesque, monstrueusement grand et trop compliqué. Eh bien, nous pouvons toujours écrire le nôtre.

pip-tools est un outil basé sur pip qui, je pense, peut aider à répondre à certaines des questions posées par les personnes sur ce fil : https://github.com/jazzband/pip-tools

Si vous lui donnez une liste de dépendances abstraites (c'est-à-dire sans versions spécifiées), il vous indiquera les versions spécifiques de chaque exigence et dépendance à installer.

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- est à peu près aussi idiot (plus idiot si vous comptez que c'est une autre chose que vous devez installer [plus idiot si vous avez besoin du support de python2])

De plus, tout l'intérêt des outils pip (& pipenv) peut être accompli avec un pip simple et un fichier de contraintes. ( pip install -r reqs -c constraints; pip freeze > constraints ).

Ajouter une nouvelle option sur pip install qui ferait que pip ne fonctionnerait que jusqu'à la résolution des packages et imprimerait les packages sélectionnés et quitterait (en sautant l'installation) ?

Je viens d'effectuer un entretien ménager important ici, et ce problème concerne maintenant le suivi / la discussion de ce cas d'utilisation + si / comment pip changerait pour répondre à cette demande de nouvelle fonctionnalité.

J'ai caché tout un tas de commentaires, allant de commentaires très anciens qui n'ont plus le contexte pertinent attaché, à ceux qui incluaient des "pirates/pépites de script potentielles" pour faire 90% du travail pour cela. Pour ce dernier groupe, veuillez vous abstenir de publier davantage de ces derniers ici - il existe d'autres forums d'assistance aux utilisateurs où ces suggestions seraient plus appropriées, pas sur le forum pour discuter de la façon d'implémenter le correctif dans l'outil lui-même. :)

Toutes mes excuses à tous ceux dont le commentaire réellement pertinent et utile a été caché ; Je n'arrivais vraiment pas à comprendre le contexte de beaucoup de commentaires et le vôtre a peut-être été caché dans des dommages collatéraux.

Comme ce ticket est bloqué par le développement du résolveur de dépendances (#988), j'ai pensé mentionner ici que l'équipe recherche l'aide de la communauté pour avancer sur ce sujet.

Nous devons mieux comprendre les circonstances dans lesquelles le nouveau résolveur échoue, nous demandons donc aux utilisateurs de pip avec des dépendances complexes de :

1. Essayez le nouveau résolveur (utilisez la version 20.1, exécutez --unstable-feature=resolver )
2. Cassez-le :P
3. Signaler un problème

Vous pouvez trouver plus d'informations et des instructions plus détaillées ici

Un cas d'utilisation que j'aimerais souligner et qui découle de l'expérimentation dans # 7819 que je ne vois pas encore mentionné dans ce fil est l' enregistrement spécifique d'URL pour le téléchargement et l'installation ultérieurs de packages , qui est une fonctionnalité légèrement orthogonale aux fichiers de verrouillage discutés ci-dessus, et est particulièrement utile pour consommer les résultats d'une résolution de pip sans avoir à télécharger de gros fichiers.

Nous avons développé une méthode de packaging pour les grandes applications d'apprentissage automatique chez Twitter que nous appelons "ipex" qui peuvent être expédiées sans contenir de code tiers jusqu'à leur première exécution (ce qui réduit considérablement leur taille). Dans le cas de pantsbuild/pants#8793, nous générons une archive pex exécutable qui appelle la bibliothèque d'exécution pex pour résoudre les exigences (pex exécute pip sous les couvertures). Je travaille actuellement sur un prototype qui remplace l'étape de résolution pex/pip complète au moment de l'exécution par un remplacement qui enregistre uniquement les URL à partir desquelles télécharger les dists (le req.link ). Ceci est extrêmement rapide en pratique (et il peut être mis en cache de manière très granulaire), puisque le téléchargement et la copie de fichiers pour créer le fichier pex "hydraté" peuvent être effectués entièrement en parallèle.

Cette capacité (de télécharger et d'installer des tonnes de roues/non-roues en parallèle) repose en plus sur l'exposition de l'URL de n'importe quelle roue ou non-roue que nous mettrions dans un fichier de verrouillage, ce que je ne vois pas encore mentionné ici. Cela permet aux pantalons d'invoquer pip exactement une fois (pour résoudre les URL de téléchargement) lorsqu'un fichier ipex déshydraté est créé, puis le résultat de cette étape de "résolution" avec les URL peut être consommé pour télécharger les exigences lorsque le fichier ipex est invoqué pour la première fois sur un complètement machine différente sans avoir à invoquer à nouveau pip.

Il a fallu beaucoup d'efforts dans # 7819 pour propager les URL des entrailles du résolveur v1 à la sortie. C'était beaucoup moins d'efforts la dernière fois que j'ai essayé de le faire fonctionner avec le résolveur v2. En ce moment, nous prévoyons probablement d'expédier une version expérimentale d'une commande --dry-run ou resolve en interne qui crache des URL de téléchargement - si nous réussissons, cela devrait, espérons-le, aider à en afficher problèmes restants avec --unstable-feature=resolver en attendant ! :D :D

Comme vous l'avez mentionné, la conception du format de fichier de verrouillage est orthogonale à l'implémentation du résolveur. Cependant, cela signifie également qu'il est hors de portée du projet pip actuel. Il y a eu des discussions sur le sujet (avertissement : très long fil de discussion), mais compte tenu du manque de temps disponible pour les développeurs, cela signifie à son tour qu'une discussion sérieuse n'aura probablement pas lieu avant que le résolveur ne soit au moins stabilisé.

Merci pour le lien!!

Le dimanche 24 mai 2020 à 19:34 Tzu-ping Chung [email protected]
a écrit:

Comme vous l'avez mentionné, la conception du format de fichier de verrouillage est orthogonale à la
Implémentation du résolveur. Cependant, cela signifie également qu'il est hors de portée pour le
projet pip en cours. Il y a eu des discussions sur le sujet
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(attention : fil de discussion très long), mais compte tenu du manque de temps de développement
disponible, cela signifie à son tour qu'une discussion sérieuse ne sera probablement pas
arriver avant que le résolveur ne soit au moins stabilisé.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pip/issues/53#issuecomment-633346918 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
.

@cosmicexplorer Avez-vous déjà expédié cette version expérimentale d'une commande --dry-run ou resolve en interne ? Si oui, comment ça se passe ?

Vous avez peut-être remarqué que je suis extrêmement intéressé par cette fonctionnalité 😄

Utiliser quelque chose comme :

pip install foo==

donne une liste de toutes les versions disponibles (pour un package pypi disponible valide, molécule dans ce cas):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

mais ce serait bien de pouvoir obtenir la version qui serait installée à l'aide de pip sans la télécharger et/ou l'installer sur dev/null :-)

Joli tour !! Utile et pratique !! Vraiment impressionnant !!

hacks potentiels / pépites de script ... veuillez vous abstenir de publier davantage de ces derniers ici - il existe d'autres forums de support utilisateur où ces suggestions seraient plus appropriées, pas sur le forum pour discuter de la façon d'implémenter le correctif dans l'outil lui-même. :)

Ce n'est pas pour rien, vraiment, mais c'est le genre de chose qui arrive quand on laisse un bogue persister très longtemps (7,56 ans dans le cas de ma dernière "pépite", bien que ce bogue toujours ouvert ait maintenant 9,25 ans vieux). Les gens partagent leurs solutions de contournement.

Je doute également que masquer les commentaires, y compris les solutions de contournement, aidera les gens à réaliser que la solution de contournement qu'ils sont sur le point de publier dans un commentaire n'est pas nécessaire (en partie parce que personne ne va cliquer sur tous ces commentaires masqués pour voir ce qui a déjà été dit). Quand quelqu'un arrive à un bogue vieux de dix ans et ne trouve pas une sorte de progrès ou de direction de la part des responsables, ou une solution de contournement, j'ose dire qu'ils considéreront le partage d'une solution de contournement comme nécessaire, car faire souffrir d'autres personnes à travers le travail que vous 'ai déjà fait lui-même est inutile.

Et oui, ce commentaire est également ce qui se passe lorsque ce que vous avez fait en réponse à ce bogue toujours ouvert se produit.

Ne vous inquiétez pas, pour ma part, je n'ajouterai plus de commentaires non provoqués à moins que pip ne casse à nouveau mon script et que ce bogue soit toujours ouvert.

Merci pour ce que vous faites. :)

@brainwane @ei8fdb Je veux signaler ce problème comme important du point de vue UX - lié à # 8377

Résumé de haut niveau basé sur ma compréhension :

• avec le nouveau résolveur, pip sera moins permissif et refusera d'installer des dépendances conflictuelles ( ResolutionImpossible )
• les conflits de dépendance peuvent exister n'importe où dans l'arborescence des dépendances
• les outils existants (pipdeptree pip-conflict-checker) n'affichent que les packages déjà installés, pas ceux qui ont été demandés, mais qui ont échoué
• Il n'y a actuellement aucun moyen pour les utilisateurs de déterminer où se situe le conflit de dépendances _avant_ qu'un paquet soit installé, ou lorsqu'une erreur ResolutionImpossible se produit (autre que d'inspecter manuellement les dépendances de chaque projet)

En bref, nous avons besoin d'un moyen pour les utilisateurs de détecter d'éventuels conflits de dépendance en fonction de leurs exigences de niveau supérieur (c'est-à-dire les packages spécifiés dans requirements.txt ou entrés directement dans la ligne de commande).

Si nous décidons de le faire, le nom de drapeau proposé ( --dry-run ) devrait être recherché/discuté.

@uranusjr @pfmoore - corrigez-moi si je me trompe ou si j'ai raté quelque chose en fonction de notre discussion. THX

@nlhkabu Je suis d'accord avec tous vos commentaires ci-dessus. Cependant, juste pour être clair, un style de commande --dry-run permettra aux utilisateurs de vérifier s'il y aura un conflit de dépendance. Mais comme décrit, il n'offrira aucune aide supplémentaire pour diagnostiquer pourquoi le conflit existe. Il s'agit donc essentiellement d'une commande d'installation "regarder avant de sauter", contrairement à l'approche normale "demander pardon" où nous installons si nous le pouvons, mais ne faisons rien et signalons l'erreur sinon.

Ce que cela ne fournit pas, et qui est quelque chose que l'OMI serait très utile (soit en tant que sous-commande pip, soit tout aussi utile qu'un outil tiers) est un moyen de répertorier à quoi ressemble l'arbre de dépendance à partir duquel pip fonctionne . (Cela ne nécessite pas de résolveur ni d'étape d'installation réelle, il s'agit "simplement" de répertorier de manière transitive les métadonnées de dépendance à partir des sources du package).

Cela pourrait également prendre la forme d'une commande pip resolve .

pip resolve est ce à quoi la plupart s'attendraient, appelez-le ainsi s'il vous plaît 😄 Cela permettrait également éventuellement ses propres drapeaux.

Merci pour la clarification @pfmoore. Du point de vue de l'utilisateur, je ne sais pas à quel point --dry-run est utilisé sans resolve ?

IMO, il ne suffit pas de dire aux utilisateurs qu'ils obtiendront une erreur - nous devons également leur donner suffisamment d'informations pour trouver où elle se trouve et faire quelque chose à ce sujet.

Alors, imaginez qu'un utilisateur exécute --dry-run ... nous pourrions inclure quelque chose comme ceci dans la réponse :

Conflit de dépendance détecté. pip ne pourra pas installer d 1.0 et c 1.0.
Le conflit est causé par :
d 1,0 dépend de E==2,0
c 1.0 dépend de E==1.0
Exécutez pip resolve pour inspecter l'arborescence des dépendances.

Nous pourrions également réutiliser pip resolve dans le message d'erreur ResolutionImpossible (voir #8377), ce qui serait une grande victoire.

@pradyunsg avons-nous un billet séparé pour pip resolve ?

@nlhkabu https://github.com/pypa/pip/issues/7819

De plus, juste pour être clair, je pense que le cas d'utilisation prévu pour pip resolve est soit (en supposant le succès):

1. rediriger la sortie vers un fichier (qui sera généralement validé), ou
2. d'autres outils utiliseront/analyseront la sortie

Pour Twitter, en utilisant l'outil "ipex" comme décrit dans # 7819, nous créons des fichiers pex exécutables à l'aide d'une commande pip resolve qui affichera les URL de téléchargement pour toutes les distributions résolues au lieu de télécharger quoi que ce soit (pas encore utilisé en production ). Ceci, ainsi que plusieurs autres optimisations, par exemple # 8448, permet de créer ces fichiers ipex en quelques secondes. Ces fichiers ipex téléchargent ensuite toutes les sorties de distributions de la commande pip resolve la première fois qu'elles sont exécutées, à partir du même centre de données -- cela permet aux fichiers ipex eux-mêmes d'être en mégaoctets au lieu de gigaoctets, ce qui améliore le temps de téléchargement de nombreuses régions.

Donc, nous intégrons essentiellement une version json de la sortie pip resolve en tant que fichier dans l'archive pex, et nous avons un script d'amorçage lu pour télécharger les distributions en parallèle.

Une mise à jour pour ceci?

Quelqu'un doit d'abord comprendre comment présenter le résultat de la résolution. Les mainteneurs de pip AFAIK impliqués dans le travail de résolveur s'efforcent tous d'améliorer le résolveur lui-même en ce moment, donc cela nécessiterait une aide extérieure pour aller de l'avant.

Corrigez-moi si je me trompe, mais ce qui suit semble être vrai :

• L'installation d'un package Python implique l'exécution de son fichier setup.py.
• Sans une option --dry-run , il n'existe aucun moyen simple et fiable de savoir quels packages le résolveur de pip choisira d'installer.

Par conséquent, il me semble que l'exécution pip install signifie consentir à exécuter du code à partir d'une sélection plutôt arbitraire de packages PyPI sur sa machine sans moyen simple et fiable de l'auditer. Cette sélection dépend de manière récursive des choix de dépendance et des pratiques de sécurité des auteurs de packages individuels.

Cela dépend si le projet et la version à installer n'ont qu'une distribution source (sdist, contient setup.py) ou également wheels (distribution construite, contient un fichier texte de métadonnées, est installé par des copies de fichiers sans exécution de code arbitraire)

Même avec --dry-run, il est probable que pip devra exécuter des backends de construction pour les packages (ce qui, pour setuptools, implique l'exécution de setup.py) qui n'ont pas de roues.