Pip: Nouveau résolveur : déploiement, boucles de rétroaction et flux de développement

Je ne sais pas comment vous l'avez planifié, mais un commentaire est que je vous encourage à essayer de partager le code autant que possible entre le nouveau code et le code actuel, et à refactoriser le code actuel pendant que vous travaillez pour permettre plus de partage entre les chemins de code nouveaux et actuels.

L'une des raisons est que si vous partagez plus de code, il y aura moins de risques de rupture lorsque vous activez et désactivez le nouveau comportement, car vous exercerez ce code partagé dans les deux états et vous n'aurez pas autant de nombreuses différences potentielles de comportement à affronter.

Cela impliquerait des CTA aux utilisateurs pour leur demander de l'essayer et de fournir des commentaires

Nos antécédents en matière d'obtention de commentaires avancés sur les nouvelles fonctionnalités ont été assez mauvais. Nous avons essayé des versions bêta, en publiant de nouvelles fonctionnalités avec des drapeaux de "désactivation" que les gens peuvent utiliser s'ils rencontrent des problèmes, de grandes campagnes de publicité pour les changements de rupture, et aucune d'entre elles ne semble avoir fonctionné.

Mon sentiment personnel est que "le rendre disponible et demander des commentaires" est une variante intéressante de ce que nous avons déjà essayé, mais finalement cela ne fera pas beaucoup de différence. Trop de gens utilisent le dernier pip avec des options par défaut dans leurs pipelines de construction automatisés et ne testent pas avant de passer à une nouvelle version de pip (nous l'avons vu avec PEP 517).

Je me demande - pourrions-nous obtenir une subvention PSF pour obtenir des ressources pour faire un grand exercice de test "dans le monde réel" pour cette fonctionnalité, ou (mieux encore) développer une infrastructure de test pour nous ? Un tel projet pourrait inclure un appel à projets pour nous faire connaître leurs flux de travail et leurs configurations, afin que nous puissions mettre en place des chemins de test garantissant que les nouvelles versions de pip ne les cassent pas. Ou même simplement utiliser une subvention pour faire appel à quelqu'un d'expérimenté dans l'aspect communication de l'obtention de bêta-testeurs pour de nouvelles fonctionnalités afin de nous aider à mettre en place un meilleur programme de test utilisateur ?

En termes de git/GitHub, il s'agit probablement de la première implémentation de fonctionnalité "expérimentale" dans pip

Je ne suis pas sûr à 100% de ce que vous entendez par là. Nous avons certainement eu de nouvelles fonctionnalités dans le passé qui ont été ajoutées alors que "l'ancienne méthode" était toujours présente. Nous n'avons pas eu tendance à les laisser "désactivés par défaut, activez-les pour les essayer", si c'est ce que vous voulez dire, mais c'est principalement parce que nous n'avons jamais trouvé de bon moyen d'obtenir des commentaires (voir ci-dessus).

J'ai passé environ 60 minutes à (re-re-re-re-re-)écrire ce post, alors maintenant je vais aller jeter un œil aux endroits de New York ! Si vous ne voyez pas de réponse rapide de ma part, c'est que je serai en mode touriste.

Je vous encourage à essayer de partager le code autant que possible entre le nouveau code et le code actuel, et à refactoriser le code actuel pendant que vous travaillez pour permettre plus de partage entre les chemins de code nouveaux et actuels.

Définitivement! C'est 80% de la raison pour laquelle je mets #5051 devant cela - j'ai l'intention de rembourser une grande partie de la dette technique que nous avons accumulée dans notre logique de construction afin qu'il devienne plus facile de le réutiliser (tout ?). Un tas de code devra être :fire: et je suis d'accord que le reste doit certainement être réutilisé autant que raisonnable.

Nous n'avons pas eu tendance à les laisser "désactivés par défaut, activez-les pour les essayer", si c'est ce que vous voulez dire

Oui, en effet. Je fais également allusion au flux de développement ici - IMO, ce serait bien de fusionner une infrastructure vide (des classes avec un tas de méthodes qui ne sont que raise NotImplementedError() qui seront étoffées dans les relations publiques ultérieures) ou on ne le fait pas couvrir tous les cas (implémentation à moitié cuite) dans la branche master tant que cela n'est utilisé que derrière le drapeau explicitement noté comme "expérimental/alpha".

re: retour d'expérience

Je suis jeune, stupide et optimiste - je veux faire de ce déploiement un opt-in, pour obtenir des commentaires proactifs et agir en conséquence. Par « proactif », je veux dire par des personnes qui sont prêtes à prendre un peu plus de temps pour essayer la fonctionnalité alpha/bêta et nous informer de son état. Je pense que si nous faisons suffisamment de bruit et que nous ciblons / atteignons stratégiquement les gens, nous pouvons obtenir de bons retours "proactifs" de la part de personnes qui ont le temps et l'énergie d'essayer de nouvelles fonctionnalités pour aider à régler les détails / problèmes.

En regardant nos récents changements "majeurs", je pense que la plupart des commentaires que nous avons reçus étaient réactifs - des utilisateurs réalisant des problèmes avec leurs flux de travail lorsqu'ils se sont cassés, puis nous ont contactés pour nous en informer. Beaucoup d'entre eux n'ont peut-être pas eu le temps d'aider à peaufiner les détails de la nouvelle fonctionnalité, ce qui cause beaucoup de frictions. Cela nous a également coûté une grande partie de notre "budget de désabonnement" [1], que je ne veux pas dépenser plus, car Python Packaging n'a plus vraiment grand-chose de toute façon [2].

FWIW, je prévois d'emprunter quelques idées au lancement de PyPI, comme faire des articles de blog à des endroits assez visibles (c'est-à-dire pas mon blog personnel), éventuellement aller sur des podcasts, des e-mails exploitables au bon moment, etc. Je recherche également plus d'art antérieur /moyens de communication via. L'une des (nombreuses!) choses que j'ai apprises à PyCon, c'est qu'il existe des canaux que nous n'utilisons pas, qui aideront à diffuser des informations mais ne chercheront pas à vérifier si nous en avons à diffuser.

Pour être clair, je ne critique pas l'approche de déploiement que nous avons prise pour le PEP 517, je pense que ça se passe bien, surtout compte tenu du fait que nous sommes tous des bénévoles. J'essaie de voir ce que nous pouvons apprendre et des éléments exploitables pour essayer d'éviter les problèmes que nous avons eus. La plupart de ces éléments impliquent plus de travail de la part des responsables et la raison principale pour laquelle je passe tout ce temps à y penser est que je considère cela comme un exercice d'apprentissage amusant sur la façon de gérer le changement.

objet : subventions

Oui, je pense que nous pouvons certainement utiliser une subvention / une personne plus expérimentée pour nous aider à comprendre l'infrastructure de communication, de déploiement et de test. Cela nécessite cependant que quelqu'un fasse le travail de rédaction des subventions et élabore des plans plus concrets que je ne peux en faire pour le moment, car je n'ai pas un nombre d'heures/semaine plus stable que je puisse garantir.

FWIW, PSF a un contrat en cours pour aider à comprendre la communication liée à PyPA/Packaging avec Changeset Consulting, alors peut-être pouvons-nous en tirer parti ?

Je ne mentionne intentionnellement pas de personnes @, car il est assez tôt dans l'état de planification pour ajouter plus de personnes à la conversation.

Notes de bas de page :

1. Un très beau terme que @ pganssle a utilisé et que je vais certainement utiliser.
2. C'est pourquoi j'ai mis le #3164 en veilleuse, bien qu'une implémentation du package "pip-cli" y soit proposée et un consensus raisonnable sur la façon dont nous voulons que le déploiement ressemble.

Je suis jeune, stupide et optimiste

:-) Et je suis parfois trop vieux, fatigué et cynique. Allons-y avec votre philosophie, ça sonne beaucoup mieux :-)

Définitivement! C'est 80% de la raison pour laquelle je mets #5051 devant cela - j'ai l'intention de rembourser une grande partie de la dette technique que nous avons accumulée dans notre logique de construction afin qu'il devienne plus facile de le réutiliser (tout ?).

Super!

De IRC à l'instant :

[sumanah] pradyunsg : y a-t-il quelque chose que la communauté pip & packaging peut faire pour vous aider à travailler plus rapidement sur le résolveur ?
....
[pradyunsg] En fait, en ce moment, les entrées sur https://github.com/pypa/pip/issues/6536 m'aideraient probablement à comprendre comment aborder le travail / obtenir des commentaires des gens, etc.
....
[sumanah] pradyunsg : re : Nouveau résolveur : Déploiement, boucles de rétroaction et flux de développement n° 6536 -- l'entrée que vous voulez est quelque chose comme : l'approche du drapeau de fonctionnalité est-elle une bonne idée ? est-ce une bonne idée d'obtenir des commentaires via un mécanisme autre que les problèmes pip GitHub ? est-ce une bonne idée d'obtenir une subvention ou similaire pour obtenir des tests manuels réels et une infrastructure de test robuste, et/ou des communications proactives ?
...
[pradyunsg] Oui -- si les idées que je propose sont bonnes. De plus, toutes les idées/approches/réflexions supplémentaires qui pourraient aider le déploiement + les commentaires à être plus fluides seraient géniales.

Alors:

L'approche du drapeau de fonctionnalité est-elle une bonne idée ? Oui.

Est-ce une bonne idée d'obtenir des commentaires via un mécanisme autre que les problèmes pip GitHub ? Oui. Nous devrions trouver des moyens automatisés d'accepter les rapports de bogues moins structurés d'utilisateurs moins experts.

Une infrastructure de test plus robuste serait-elle utile ? Oui, beaucoup, et c'est un endroit où nos sponsors pourraient peut-être nous aider.

Changeset (moi), dans le cadre du contrat existant avec PSF pour aider à la coordination/communications de PyPA, pourrait-il aider pip avec des communications proactives pour nous permettre d'effectuer des tests manuels plus systématiques dans le monde réel ? En supposant qu'il me reste des heures dans mon contrat au moment où nous voulons commencer ce déploiement, oui.

est-ce une bonne idée d'obtenir une subvention ou similaire pour obtenir plus d'aide avec l'expérience utilisateur, les communications/publicité et les tests ? Oui. Les bourses PSF seraient potentiellement intéressantes , tout comme les bourses NLNet (pour les demandes inférieures à 30 000 euros ), potentiellement le logiciel open source essentiel de Chan Zuckerberg pour la bourse scientifique , et le MOSS de Mozilla . Le groupe de travail sur l'emballage peut être le demandeur officiel. Si @pradyunsg ou @pfmoore veut faire un signe de tête "ouais, ça a l'air intéressant", je peux commencer à étudier ces possibilités avec le WG.

Si @pradyunsg ou @pfmoore veut faire un signe de tête "ouais ça semble intéressant",

Ca m'a vraiment l'air intéressant :-)

@pradyunsg ou @pfmoore veut donner un signe de tête "ouais ça semble intéressant"

_hoche la tête_ ouais ça a l'air intéressant

Une infrastructure de test plus robuste serait-elle utile ? Oui, beaucoup, et c'est un endroit où nos sponsors pourraient peut-être nous aider.

@brainwane Également pertinent ici est https://github.com/pypa/integration-test. Je pense que la mise en place de cette configuration est un autre domaine potentiel de financement - nous devrions l'ajouter à https://wiki.python.org/psf/Fundable%20Packaging%20Improvements.

D'ACCORD! J'ai commencé à parler avec la PSF et avec les gens de l'Initiative Chan Zuckerberg pour demander une subvention CZI via le groupe de travail sur l'emballage. J'ai ajouté quelques détails à la page Fundable Packaging Improvements expliquant pourquoi le nouveau résolveur de pip est important, et j'ai ajouté le integration-test à cette liste. Et j'ai commencé à rassembler des noms d'experts en expérience utilisateur qui ont la capacité de rechercher notre chaîne d'outils compliquée de distribution/installation de packages en ligne de commande, de parler avec les utilisateurs pour comprendre leur modèle mental de ce qui se passe et de ce qui devrait se passer , et conseiller les mainteneurs.

Si nous recevons de l'argent via des subventions de MOSS, CZI ou NLNET, je pense que nous obtiendrons l'argent... Octobre au plus tôt, probablement. Une subvention directement de la PSF serait probablement plus rapide, mais "Notre objectif actuel est les ateliers Python, les conférences (en particulier pour l'aide financière) et les efforts de diversité/inclusivité Python."

Une considération est que je sais que Brett et les membres du conseil de direction parlent d'investir dans la gestion de projet et envisagent d'avoir une sorte de ressources rémunérées pour gérer ces projets (triage, gestion de projet, etc.) et ils parlent avec le PSF directement. Cela vaut peut-être la peine de les contacter et de découvrir ce qu'ils font ou pensent, car j'ai entendu des discussions sur la durabilité à long terme et ce serait une bonne chose d'y participer.

Les drapeaux de fonctionnalités sont bons, les opt-ins sont bons. Une chose que vous pourriez envisager est de savoir si vous pouvez inviter au hasard les utilisateurs à essayer le résolveur (comme, très très très rarement et uniquement pour une installation à la fois, c'est-à-dire sans les forcer à l'activer en permanence). Ensuite, vous pourriez indiquer comment le résolveur a été utile (par exemple, qu'est-ce qu'il a fait pour eux ? Quels conflits a-t-il rencontrés et résolus ?)

Les personnes venant de javascript ou de rouille par exemple s'attendront également à un fichier de verrouillage quelconque, donc cela peut être quelque chose à considérer...

Désolé d'intervenir, content de voir que ça avance !

Mon sentiment personnel est que "le rendre disponible et demander des commentaires" est une variante intéressante de ce que nous avons déjà essayé, mais finalement cela ne fera pas beaucoup de différence. Trop de gens utilisent le dernier pip avec des options par défaut dans leurs pipelines de construction automatisés et ne testent pas avant de passer à une nouvelle version de pip (nous l'avons vu avec PEP 517).

En tant que l'une des personnes qui ont été mordues par certains problèmes de PEP 517 pour cette raison même, j'aimerais vraiment voir un moyen opt-in de tester les choses. Mais je ne connais ce genre de choses que parce que je me suis abonné à toutes les sources d'informations sur les emballages python que je pouvais après le problème du drapeau --no-use-pep517 . Ce que je dis, c'est que diffuser ce genre de nouvelles est difficile et c'est probablement pourquoi il est difficile d'obtenir des commentaires.

Je pense que plus de gens seraient intéressés si l'information pouvait être mieux diffusée. Est-ce ce que les ressources que vous recherchez permettraient de faire?

Pour continuer sur ce que dit jriddy, je pense également qu'il sera très difficile d'amener les gens à tester divers drapeaux de fonctionnalités s'ils doivent les connaître, apporter des modifications à leur configuration CI pour chaque nouveau drapeau, etc.

Ce qui semblerait beaucoup plus faisable, cependant, c'est s'il n'y a qu'un seul indicateur de fonctionnalité à connaître, pour tester "ce qui va suivre" en termes de changements qui doivent être testés. Ensuite, les personnes et les entreprises pourraient configurer leur CI pour l'exécuter également (sans échouer les builds pour les erreurs). Je pense à quelque chose de similaire à Rust, où ces types de modifications sont intégrées au canal "bêta" de la chaîne d'outils, et il est facile de configurer un autre canal CI pour exécuter des choses sur la chaîne d'outils bêta et envoyer des erreurs à quelqu'un.

L'essentiel est que cette configuration doit être apprise et effectuée _une seule fois_, au lieu d'avoir à se renseigner en permanence sur les nouveaux indicateurs de fonctionnalité individuels, à modifier les configurations CI ou à les tester manuellement.

Ce qui semblerait beaucoup plus faisable, cependant, c'est s'il n'y a qu'un seul indicateur de fonctionnalité à connaître,

Dans un sens, cela n'existe-t-il pas déjà sous la forme de --pre ? Le canal de sortie bêta pour pip pourrait-il simplement être une question d'exécution de pip install --upgrade --pre pip ?

Désolé d'intervenir, content de voir que ça avance !

@techalchemy s'il vous plaît, de toutes les personnes, _vous_ n'avez certainement pas à être désolé d'avoir participé à cette discussion.

Est-ce ce que les ressources que vous recherchez permettraient de faire?

Dans une certaine mesure, oui.

reg : versions bêta/"canal" pour pip

Merci d'avoir sonné @jriddy et @ chrish42. Bien que je pense qu'en général, c'est définitivement une conversation utile/importante à avoir, je pense aussi que c'est légèrement OT pour ce problème. Néanmoins, je répondrai ici une fois; si nous voulons en discuter davantage, ouvrons un nouveau sujet.

Nous avons essayé cela dans le passé - plus récemment avec le pip 10 - mais cela n'a pas bien fonctionné. Je suis un peu sceptique quant à la façon dont cela pourrait fonctionner à l'avenir également, mais je peux également imaginer que certains changements apportés à notre processus pourraient entraîner un bon fonctionnement pour nous. Peut-être que nous pourrions faire un ensemble de fonctionnalités "bêta uniquement" ou quelque chose comme ça ? J'avais imaginé -X all comme syntaxe pour cela dans #5727. Peut-être pourrions-nous reprendre cela dans le cadre de ce plan de déploiement ? Je ne sais pas. Nous devrons investir du temps et de l'énergie pour comprendre cela. :)

Comme mentionné dans https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480, je pense qu'il est important d'avoir une explication consolidée de la façon dont un solveur modifie l'expérience pip. Beaucoup de gens seront frustrés par le passage à un système plus rigide (même si les choses devraient être globalement plus fiables, elles seront bloquées là où elles ne le sont pas actuellement.

Avoir une explication centrale de la façon dont les choses ont changé et pourquoi c'est un bon changement rendra la réponse à ces personnes en colère beaucoup plus simple. Postez un lien et voyez s'ils ont d'autres questions.

L'avant-première est une bonne idée. Dans conda, nous avons un canal de pré-version, conda-canary. Nous encourageons les gens à configurer une tâche CI pour affronter Canary d'une manière qui les aide à voir si les changements de conda vont les casser. Idéalement, ils nous le font savoir avant de publier cette version. Cette chaîne a été un échec assez lamentable. La seule fois où les gens semblent vraiment l'utiliser, c'est quand ils veulent obtenir la dernière version pour corriger un bogue avec lequel ils se débattent. Nous ne recevons pas beaucoup de rapports de nos premiers utilisateurs. Je pense toujours que la pré-version est une bonne idée, car lorsqu'une version se passe mal et que les gens sont en colère contre vous pour avoir cassé leurs 700 nœuds gérés, vous pouvez dire "eh bien, il était disponible pendant une semaine avant de le publier. Pourquoi n'est-ce pas testez-vous ces éléments avant de les déployer sur 700 nœuds ?" Vous donnez aux gens l'occasion de faire en sorte que les choses fonctionnent mieux. Aidez-les à réaliser que laisser passer cette opportunité signifie plus de douleur pour eux sur toute la ligne. C'est un investissement rentable pour eux, et s'ils le font dans le cadre de leur CI, cela ne leur coûte pas de temps en dehors de la configuration.

Concernant le drapeau : je pense qu'il est préférable d'avoir une option de configuration (peut-être en plus d'un drapeau). Je ne voudrais pas passer un drapeau tout le temps. Je ne sais pas si pip a cette capacité - peut-être dites-vous aux personnes qui souhaitent un commutateur plus permanent d'utiliser la variable env correspondante?

Concernant le drapeau :

Les options CLI de pip sont automatiquement mappées sur une option de fichier de configuration et une variable d'environnement, avec les noms appropriés.

@msarahan Merci d'être intervenu, très apprécié ! :)

En ce qui concerne l'option "laissez-moi faire ce que je veux" pour ignorer les dépendances brisées, je pense qu'il serait souhaitable de structurer l'indicateur de fonctionnalité de manière à ce qu'il puisse également servir de désactivation après l'activation du résolveur par défaut (par exemple, start avec --avoid-conflicts comme opt-in, éventuellement passer à --no-avoid-conflicts comme opt-out, mais acceptez les deux options dès le départ)

Vous voudrez également considérer comment --ignore-installed interagit avec le solveur - lorsqu'il est passé, vous devriez probablement ignorer toutes les exigences pour les packages déjà installés.

Au-delà de cela, gérer les choses comme des correctifs de refactorisation plus petits pour faciliter l'intégration du résolveur est une excellente voie à suivre (c'est l'approche qui a rendu possible la nouvelle API de configuration pour CPython : beaucoup de refactorisation privée qui a finalement été suffisamment stable pour être rendue publique)

@ncoghlan Que signifie "désactiver" le résolveur ? Éviter complètement la résolution des dépendances (et donc le résolveur) est --no-deps . Je comprends qu'il est nécessaire de "ignorer les conflits de version sur ce paquet" ou quelque chose du genre.

Personnellement, je ne vois aucun intérêt à conserver la logique de résolution "garder le premier vu" plus longtemps qu'une période de transition vers un nouveau résolveur.

Cependant, s'il existe des cas d'utilisation que ces deux options ne couvriraient pas, j'aimerais vraiment les connaître. :)

Plus généralement, s'il y a des flux de travail qui ont des problèmes avec le comportement d'un résolveur strict, je suis curieux de savoir à quoi ils ressemblent, le plus tôt possible, pour pouvoir déterminer si/comment les prendre en charge.

Personnellement, je ne vois aucun intérêt à conserver la logique de résolution "garder le premier vu" plus longtemps qu'une période de transition vers un nouveau résolveur.

IDK, j'utilise cette "fonctionnalité" pour faire des trucs assez fous avec des builds, comme...

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

Dans ce cas, je lui demande de résoudre mes dépendances après avoir installé des packages très prédéterminés à partir d'une timonerie locale. Je suppose que je pourrais lire mes versions exactes dans ce fichier local-reqs pour rendre un résolveur heureux, mais j'ai en fait trouvé le comportement actuel de pip assez utile pour permettre ces types d'étapes d'injections de construction arbitraires. Cela pourrait être un cas du flux de travail de chauffage de la barre d'espace, je l'admets.

Mais peut-être que le comportement de "résolution naïve" a encore une utilité.

Je suis d'accord avec @pradyunsg. Je ne pense pas qu'il soit viable de maintenir indéfiniment le code existant et un nouveau résolveur. En tant que mainteneur de pip, je n'ai certainement aucun intérêt à faire cela.

D'un point de vue d'utilisateur final, j'accepte qu'il puisse y avoir des scénarios étranges où le nouveau résolveur pourrait ne pas faire la bonne chose. Et avoir un indicateur d'urgence "Rendez-moi l'ancien comportement" est un mécanisme de transition important (bien qu'il soit discutable de savoir si "revenir temporairement à la version précédente de pip" n'est pas aussi bon - même si des choses comme l'utilisation courante de CI qui utilise automatiquement le dernier pip, ce qui rend la promotion de cette option problématique). Mais à long terme, pourquoi aurions-nous besoin de conserver le comportement actuel ? Je peux imaginer les principales situations suivantes :

1. Bogue du résolveur. Possibilité évidente, solution facile - corrigez le bogue dans la prochaine version de pip.
2. Cas où l'ancien résolveur est erroné (génère des résultats qui ne satisfont pas aux contraintes). Nous n'avons pas l'intention de soutenir cela à l'avenir, n'est-ce pas ? (Du moins pas via quelque chose de moins extrême que l'utilisateur épinglant ce qu'il veut et utilisant --no-deps pour désactiver le résolveur).
3. Cas où l'ancien et le nouveau résolveur donnent des résultats différents, qui satisfont tous les deux aux contraintes données. Les utilisateurs peuvent ajouter des contraintes pour forcer l'ancien résultat (s'ils ne le peuvent pas, cela nous ramène à (2)). Nous devrions leur donner le temps de le faire, mais ensuite abandonner l'ancien résolveur, comme toute autre fonctionnalité obsolète.
4. Un cas marginal que nous considérons comme trop complexe/bizarre à supporter. C'est comme (3), mais où nous n'affirmons pas que le nouveau résolveur donne le "bon" résultat. Les utilisateurs peuvent toujours modifier les contraintes pour éviter le cas bizarre, ou épingler et utiliser --no-deps . Mais en fin de compte, nous disons "ne faites pas ça", et si les utilisateurs ignorent ce message, à un moment donné, nous supprimons à nouveau l'ancien résolveur disant "nous vous avons prévenu".

Y en a-t-il d'autres que j'ai ratés ? En particulier, partout où il n'est pas possible de déprécier puis de supprimer l'ancien résolveur ?

Au fait, quel est le meilleur endroit pour poster des scénarios "voici un cas limite auquel j'ai pensé", afin qu'ils ne se perdent pas ? Je pense qu'il serait utile de collecter autant de situations étranges que possible à l'avance, ne serait-ce que pour commencer tôt à écrire des cas de test :-)

PS Nous devrions probablement aussi, dans le cadre du travail de préparation pour le nouveau résolveur, étudier quels sont les problèmes de contraintes "typiques" (basés sur ce qu'il y a sur PyPI). Pour ma part, il est assez rare que j'ai quelque chose de plus complexe que "pip install". Il serait dommage de s'enliser dans les dossiers complexes au point de perdre de vue la grande majorité des plus simples.

1. le résolveur est trop lent (voir conda). Si je dois choisir entre un résolveur de plus de 20 minutes ou le comportement actuel, je veux souvent le comportement actuel (ou du moins essayer ; dans de nombreux cas, il arrivera que le résultat soit correct).

2. métadonnées erronées. ce n'est pas vraiment un problème aujourd'hui, mais il est facile d'imaginer des cas qui devraient pouvoir être résolus mais qui ne le sont pas. Les métadonnées PyPI sont en pire état que les métadonnées conda/conda-forge, et c'est déjà un problème pour conda. si c'est faux et qu'en tant qu'utilisateur, je ne peux pas trouver de solution, je voudrai obtenir une option de désinscription.

@rgommers Pour 6, l'option de style "ignorer les conflits de version sur ce package" pourrait fonctionner, n'est-ce pas?

Merci, @rgommers - ce sont de bons points.

Le résolveur est trop lent, je compterais comme un bogue de résolveur. S'il ne peut pas donner de résultats suffisamment performants sur des cas simples, ce n'est pas adapté à mon avis. Si d'un autre côté vous avez un réseau de contraintes massivement complexe qui prend plus de temps avec un résolveur complet (j'espère que 20 minutes est une exagération, je ne considère pas cela acceptable en aucune circonstance !), alors nous entrons dans "des choses que nous considérer comme trop complexe pour supporter" le territoire. Autrement dit, quelqu'un a-t-il essayé de demander à conda de fournir un résolveur "rapide et sale" inexact mais rapide? S'ils ne le font pas (et je suis presque sûr qu'ils ne le feraient pas), alors pourquoi est-il raisonnable de s'attendre à ce que pip le fasse ?

De mauvaises métadonnées sont certainement quelque chose que je considérerais comme "nous ne supporterions pas cela" (rappelez-vous, je parle ici de "après une période d'obsolescence" !). Donner aux utilisateurs le temps de corriger les métadonnées et fournir une option de clause d'échappement "ignorer les conflits de version sur le package X" est suffisant à l'OMI, nous ne devrions pas nous attendre à conserver toutes les anciennes machines simplement parce que certaines personnes ne répareront pas leurs métadonnées.

Mais oui, rendre public le fait que nous avons besoin de bonnes métadonnées parce qu'un résolveur précis suit la règle "garbage in, garbage out" et surveiller la façon dont les gens réagissent à ce message fait partie intégrante du processus de déploiement.

Je lui demande de résoudre mes dépendances après avoir installé des packages très prédéterminés à partir d'une timonerie locale.

@jriddy La stratégie de résolution "utiliser l'installation existante si compatible" fonctionnera pour cela.

quel est le meilleur endroit pour poster des scénarios "voici un cas limite auquel j'ai pensé", afin qu'ils ne se perdent pas ?

https://github.com/pradyunsg/zazo/

Pour 6, l'option de style "ignorer les conflits de version sur ce paquet" pourrait fonctionner, n'est-ce pas ?

oui, cela semble être la bonne option

(J'espère que 20 minutes est une exagération, je ne considère cela acceptable en aucune circonstance !), alors nous entrons dans le territoire des "choses que nous considérons trop complexes pour être prises en charge". Autrement dit, quelqu'un a-t-il essayé de demander à conda de fournir un résolveur "rapide et sale" inexact mais rapide? S'ils ne le font pas (et je suis presque sûr qu'ils ne le feraient pas), alors pourquoi est-il raisonnable de s'attendre à ce que pip le fasse ?

Il y a beaucoup de gens qui se plaignent des performances de conda , et ils écoutent - mais c'est beaucoup de travail, voir leurs récents articles de blog. Je ne sais pas s'il y aura une option conda rapide et sale. Cependant, il existe des solutions connexes (hacks) comme conda-metachannel qui vous permettent d'élaguer le graphique de dépendance (inclure/exclure manuellement les packages) pour obtenir une solution plus rapidement. Je pense donc que cela va dans le même sens.

Cependant, gardez à l'esprit que cela sera _définitivement_ nécessaire, sauf si vous :

• faire un bien meilleur travail que conda tout de suite (pas trop probable, ce n'est pas comme si ces gars ne savaient pas ce qu'ils font - c'est juste un problème vraiment poilu).
• n'ont que des problèmes plus petits à résoudre (j'espère que ce n'est pas vrai, PyPI est grand et avec de bonnes métadonnées, les problèmes devraient être grands)

Les mauvaises métadonnées sont certainement quelque chose que je considérerais comme "nous ne prendrions pas cela en charge"

Assez juste. Toute la position sur "nous n'appliquons pas les métadonnées correctes" n'aide pas ici cependant. A moins que ça ait changé récemment ? (et je sais, c'est une chose PyPI pas une chose pip - mais c'est lié).

Je ne suis pas sûr que vous ayez vraiment les options que vous pensez avoir.

Qu'est-ce qu'un résolveur rapide et sale fait différemment d'un résolveur précis ? Qu'est-ce qu'il baisse pour être plus rapide ? Les contraintes sont des contraintes - elles ne viennent pas en grades. Soit vous les satisfaisiez, soit vous ne les satisfaisiez pas. Peut-être pourrez-vous les satisfaire uniquement par nom pour commencer, puis par version, etc.

Lorsque les gens sont contrariés par la lenteur de Conda, c'est essentiellement toujours à cause de mauvaises métadonnées. Gardez à l'esprit que vous serez blâmé pour toute lenteur perçue, quelle qu'en soit la cause profonde. De mauvaises métadonnées sont parfois une contrainte incorrecte, mais le plus souvent c'est l'absence de contrainte qui permet de considérer une option beaucoup plus ancienne et indésirable. Conda s'est considérablement amélioré récemment en faisant une petite chose : supprimer notre ancienne collection de logiciels qui avaient des contraintes inadéquates (surtout trop ouvertes). Ces contraintes ouvertes ont amené conda à explorer de très mauvaises solutions nécessitant de nombreuses rétrogradations. C'est là que la résolution a pris littéralement des heures. Les rétrogradations sont des opérations très, très coûteuses en raison de la façon dont elles peuvent se succéder, chaque étape devenant moins contrainte et plus coûteuse.

Le problème avec la mentalité "garbage in, garbage out" est qu'en tant que mainteneurs du solveur, vous tenez le sac. À moins que vous n'ayez une très bonne heuristique pour ce qui est des ordures, vous êtes impuissant. Vous finissez par être celui qui doit enquêter sur la lenteur du solveur, isoler le problème, puis demander à la source du problème de résoudre les problèmes. Ce n'est pas une bonne position, croyez-moi. Nous passons une tonne de temps à essayer d'expliquer aux gens pourquoi conda prend une éternité ou ne fonctionnera pas avec un mélange de conda-forge, bioconda ou d'autres canaux tiers. Nous finissons par devoir faire le travail de détective et dire à ces canaux tiers ce qu'ils doivent réparer. C'est nul.

Toute comparaison avec conda doit tenir compte du fait que conda adopte une approche très différente du problème. Conda a une source géante de métadonnées et résout tout à la fois, mais pip résout et optimise de manière récursive chaque chose à la fois (en revenant en arrière si nécessaire). Cela peut vous offrir différentes voies d'optimisation.

@wolfv a récemment exploré l'utilisation de libsolv pour conda. Il était finalement frustré de ne pas pouvoir l'amener à donner les mêmes réponses que conda. Cela se résumait à cette différence entre les approches. Libsolv est un solveur de backtracking. Il peut servir de complément optionnel compilé à pip pour accélérer les choses, bien que je sache que vous êtes sensible à ne pas inclure de code compilé directement avec pip.

( @pradyunsg vient de publier sa mise à jour d'août sur son blog .)

Certaines des questions et des besoins que les gens soulèvent maintenant sont des choses que nous devons commencer à rassembler maintenant, comme les cas de test.

Mais aussi : quel calendrier pensons-nous être réaliste pour ce déploiement ? Cela dépend beaucoup de la santé et du temps libre de Pradyun, et de la disponibilité de la révision du code par d'autres responsables de pip, et si nous obtenons des subventions pour lesquelles nous postulons, mais je pense que la séquence est quelque chose comme :

• build logical refactor: en cours, fait entre décembre et février
• Recherche et conception UX, construction d'infrastructures de test, discussion avec les utilisateurs en aval des indicateurs de configuration et des calendriers de transition : nous avons besoin de financement pour cela ; le premier démarrage est probablement décembre, prendra 2-3 mois
• introduire les abstractions définies dans resolvelib/zazo lors des tests alpha : cela prendra quelques mois, donc, en estimant prudemment, mai 2020 ?
• adopter une meilleure résolution des dépendances et effectuer des tests bêta : ?

Est-ce correct? Qu'est-ce que je rate?

Je demande parce qu'une partie du travail de collecte d'informations est un travail qu'un chef de projet et/ou un chercheur UX devrait faire, à mon avis, et parce que certains progrès sur https://github.com/pypa/packaging-problems/issues/264 et d'autres questions pourraient répondre aux préoccupations que les gens ont soulevées ici.

De mauvaises métadonnées sont parfois une contrainte incorrecte, mais le plus souvent c'est l'absence de contrainte qui permet de considérer une option beaucoup plus ancienne et indésirable.

Étant donné que l'utilisation de dépendances sans contraintes ou >= some_old_version est la règle plutôt que l'exception pour setup.py / pyproject.toml , ce sera un problème. Peu m'importe s'il s'agit d'une "contrainte incorrecte" ou d'un solveur devant faire des choix différents - c'est l'état des métadonnées sur PyPI.

Ces contraintes ouvertes ont amené conda à explorer de très mauvaises solutions nécessitant de nombreuses rétrogradations.

Vous êtes l'expert ici, mais n'y a-t-il pas des solutions pragmatiques à cela ? Dans la majorité des cas, aucune rétrogradation n'est nécessaire, alors n'essayez que cela en premier. Ensuite, rétrogradez une seule version pour chaque package. Si vous avez besoin de rétrograder davantage, c'est presque toujours la mauvaise solution (cela peut être dû à de mauvaises métadonnées ou à autre chose).

En fait, je ne sais pas si pip _peut_ même rétrograder les choses. Il avait d'abord une stratégie "tout mettre à niveau" trop agressive, maintenant "mettre à niveau au besoin" fonctionne plutôt bien. Je ne l'ai jamais vu rétrograder quoi que ce soit, et en pratique, cela fonctionne plutôt bien pour une utilisation régulière.

Un exemple de rétrogradation auquel conda doit faire face, mais pas pip : les utilisateurs d'anaconda ou de miniconda avec python 3 commencent avec python 3.7. Les utilisateurs doivent parfois installer quelque chose qui n'est disponible que pour Python 3.6. Le solveur doit rétrograder python et tous les autres packages non noarch. Il s'agit d'un cas particulier qui pourrait peut-être être optimisé en ayant un comportement spécial pour les changements de version de python, mais il illustre le fait que les changements dans un package peuvent nécessiter des rétrogradations vers un autre. "Cela a fonctionné jusqu'à présent" est une chance stupide, pas ce qui fonctionne réellement tout le temps.

En ce qui concerne la restriction des versions, vous ne pouvez pas l'appliquer dans la résolution elle-même. Vous avez vos contraintes, et toute sorte d'"ouverture par une version" ne peut pas espérer être assez générale, car elle est différente pour chaque paquet. Vous pouvez cependant couper les métadonnées par version avant le solveur. C'est ce qu'est "current_repodata.json" de conda. Uniquement la dernière version. Cela rend les choses très rapides quand cela fonctionne, mais les gens seraient vraiment en colère si c'était le seul repodata. Les choses ne seraient pas reproductibles et ils seraient frustrés que des spécifications qui fonctionnent un jour ne le soient plus le lendemain. Nous fournissons une alternative aux données de dépôt complètes et prévoyons également d'introduire des sous-ensembles temporels, avec uniquement les versions les plus récentes disponibles à des moments donnés. L'ouverture incrémentielle des données d'index disponibles pourrait être un concept plus utile avec le solveur de backtracking.

pip _peut_ même rétrograder les choses.

Il peut - pour pip, la rétrogradation n'est qu'une étape de désinstallation-installation comme la mise à niveau. Et il rétrograde lorsqu'il voit une contrainte qu'on lui a demandé de satisfaire.

Ce qui suit rétrograde les outils de configuration - tant que c'est la première chose que pip voit :

pip install "setuptools < 20.0"

quel est le meilleur endroit pour poster des scénarios "voici un cas limite auquel j'ai pensé", afin qu'ils ne se perdent pas ?

https://github.com/pradyunsg/zazo/

Merci, je garde ça en tête. Bien qu'en y repensant, mon "cas pathologique" n'est pas vraiment pathologique. Il s'agit principalement d'un cas extrême du fait que pour connaître les métadonnées de dépendance d'un package, vous devez télécharger et décompresser le package, et dans certains cas, cela peut déclencher le téléchargement de nombreux packages uniquement pour les rejeter. Cela pourrait être une limitation importante du protocole "index simple" que nous devons résoudre, mais ce n'est pas directement un problème de résolveur.

Un exemple de rétrogradation auquel conda doit faire face, mais pas pip : les utilisateurs d'anaconda ou de miniconda avec python 3 commencent avec python 3.7. Les utilisateurs doivent parfois installer quelque chose qui n'est disponible que pour Python 3.6. Le solveur doit rétrograder python et tous les autres packages non noarch. Il s'agit d'un cas particulier qui pourrait peut-être être optimisé en ayant un comportement spécial pour les changements de version de python, mais il illustre le fait que les changements dans un package peuvent nécessiter des rétrogradations vers un autre. "Cela a fonctionné jusqu'à présent" est une chance stupide, pas ce qui fonctionne réellement tout le temps.

C'est aussi un cas où normalement vous _ne voulez pas rétrograder_. En tant qu'utilisateur, je préférerais de loin recevoir une exception me disant que le paquet n'est pas disponible, et me laisser installer explicitement 3.6 si c'est ce que je veux.

Un autre exemple est l'incohérence entre les canaux. Exemple récent : nous étions à Python 3.7.3, alors base a obtenu 3.7.4 . Je ne me soucie pas de ces différences de version, et la plupart des utilisateurs ne le feront pas. Un "ne rien faire" par défaut serait bien mieux que "hey .4 > .3 , mettons à niveau cela et changeons ensuite les canaux des autres packages en base si nous le devons (même si cela les rétrograde)".

Nous fournissons une alternative aux données de dépôt complètes et prévoyons également d'introduire des sous-ensembles basés sur le temps, avec uniquement les versions les plus récentes disponibles à des moments donnés.

Cela semble être une amélioration très utile.

Le problème avec la mentalité "garbage in, garbage out" est qu'en tant que mainteneurs du solveur, vous tenez le sac. À moins que vous n'ayez une très bonne heuristique pour ce qui est des ordures, vous êtes impuissant.

Ouais c'est vrai. Je pense que chaque IDE, distribution ou "interface commune à un tas de choses" a ce problème.

Ce qui suit rétrograde setuptools

C'est une rétrogradation demandée par l'utilisateur. Un indirect est ce que je voulais dire (par exemple setuptools<20.0 dans pyproject.toml`). Cela fonctionnerait aussi, je suppose, mais c'est rare dans la pratique.

Le problème avec la mentalité "garbage in, garbage out" est qu'en tant que mainteneurs du solveur, vous tenez le sac.

100 % d'accord. C'est quelque chose qui doit être manipulé avec beaucoup de précaution. Mais à l'inverse, essayer de trouver un comportement sain pour n'importe quel vieux bric-à-brac n'est pas viable - nous devons tracer une ligne quelque part .

Pour rappel, cette discussion a été déclenchée par la question de savoir si nous devions conserver indéfiniment le résolveur existant. Je ne suis pas sûr qu'aucun de ces points ait vraiment un impact sur cette question - le résolveur existant n'est pas correct, le mieux que vous puissiez dire est que c'est un comportement cassé que les gens connaissent. Je maintiens donc ce que j'ai dit plus haut, il n'y a aucune raison de conserver l'ancien résolveur au-delà d'une période de transition initiale.

Et en fait, pour une grande partie des cas d'utilisation, l'ancien et le nouveau résolveur donneront probablement les mêmes résultats de toute façon.

"Bien" n'a pas d'importance pour les utilisateurs lorsqu'ils sont brisés par vos modifications. Tout changement de comportement exaspérera absolument un certain nombre d'utilisateurs. Leur dire que leur flux de travail est erroné et qu'ils doivent changer n'a pas été une stratégie très efficace pour moi. Je pense qu'il faut jouer à l'oreille. Je ne voudrais certainement pas conserver l'ancien résolveur pour toujours, mais vous devez probablement donner aux gens un moyen de le conserver - comme en faire un plugin que quelqu'un d'autre adopte et maintient, et les gens peuvent l'installer séparément de pip.

essayer de trouver un comportement sain pour n'importe quel vieux bric-à-brac n'est pas viable - nous devons tracer une ligne quelque part.

Oui, mais qu'est-ce que le "vieux bric-à-brac" ? Qu'est-ce qui le distingue ? Qu'en est-il des mauvais déchets par rapport aux bons déchets (en gardant à l'esprit que plus récent n'est pas toujours meilleur) ? Mon conseil est de passer beaucoup de temps à rendre le solveur très débogable. Facilitez la tâche des utilisateurs (et pas seulement de vous en tant qu'expert) pour savoir où les choses tournent mal afin de faciliter l'identification du problème des mauvaises métadonnées et de la nature de ces mauvaises métadonnées. C'est une compétence que la plupart des utilisateurs n'ont pas actuellement, et honnêtement, la plupart des utilisateurs que j'ai vus ne veulent pas avoir cette compétence. Je ne pense pas que vous (ou conda d'ailleurs) serez jamais en mesure d'avoir une heuristique automatique complètement précise pour le mal contre le bien.

C'est aussi un cas où vous ne voulez normalement pas rétrograder. En tant qu'utilisateur, je préférerais de loin recevoir une exception me disant que le paquet n'est pas disponible, et me laisser installer explicitement 3.6 si c'est ce que je veux.

@rgommers , conda 4.7 est passé à ceci - nécessitant la spécification python explicite pour modifier les versions mineures. Les gens l'ont détesté. Je n'ai aucune idée de la fraction de la population que représentent les personnes vocales, mais beaucoup de gens n'aiment vraiment pas le fait qu'ils pouvaient autrefois conda install quelque chose, et maintenant ils ne le peuvent plus. Ils ne se soucient pas beaucoup de la raison, et ils sont pour la plupart apaisés par la réponse, mais nous avons toujours l'hostilité à gérer en attendant. Juste un autre exemple de

"Bien" n'a pas d'importance pour les utilisateurs lorsqu'ils sont brisés par vos modifications.

Un autre exemple est l'incohérence entre les canaux. Exemple récent : nous étions à Python 3.7.3, puis base a obtenu 3.7.4. Je ne me soucie pas de ces différences de version, et la plupart des utilisateurs ne le feront pas. Un "ne rien faire" par défaut serait bien mieux que "hé .4> .3, mettons à niveau cela, puis changeons les canaux d'autres packages en base si nous le devons (même si cela les rétrograde)".

C'est un point beaucoup plus compliqué. Vous proposez essentiellement différents critères d'optimisation. Vous avez peut-être vu les 11 étapes actuelles dans notre article de blog à l' adresse https://www.anaconda.com/understanding-and-improving-condas-performance/

Celles-ci sont extrêmement délicates et il n'y a pas d'optimum global qui satisfasse toutes les situations. Compte tenu de la compatibilité binaire, et des canaux en tant qu'îlots de ladite compatibilité, la forte priorité des canaux est assez essentielle. Les versions Python n'ont pas d'importance, vous avez raison, mais il n'y a actuellement aucun moyen d'exprimer une contrainte de compatibilité binaire par rapport à une contrainte de version pure et simple. Vous auriez besoin de cela pour réfléchir à votre idée de laisser les choses tranquilles. Sinon, vous seriez rapidement dans l'enfer de l'incompatibilité binaire.

Bonjour, merci @msarahan de m'avoir mentionné dans ce numéro. Je voulais intervenir plus tôt mais je n'ai pas trouvé le temps.

En effet, j'ai beaucoup expérimenté en utilisant libsolv comme solveur pour les spécifications conda. Et cela fonctionne - la différence restante maintenant est que conda ne se soucie pas beaucoup du numéro de build, mais libsolv dans la façon dont il est codé (et avec le solveur de retour en arrière) le fait. Même en utilisant le repodata complet, libsolv est vraiment rapide - j'irais jusqu'à dire que la vitesse de libsolv est assez rapide pour ne pas être ennuyeuse :)

Ma grande contribution à libsolv a été de le rendre compatible multiplateforme afin qu'il compile désormais sur Windows, OS X et Linux.

Je préconiserais totalement d'utiliser libsolv pour un nouveau résolveur, même s'il s'agit d'un blob de code compilé (au moins c'est rapide) et @mlschroe pourrait être disponible pour aider - il a beaucoup aidé avec le support libsolv pour la conda matchspec.

D'un autre côté, je ne sais pas à quel stade se trouve le développement du résolveur et s'il est déjà trop tard maintenant, et si le code compilé est acceptable ou non.

Vous avez peut-être vu les 11 étapes actuelles dans notre article de blog à l' adresse https://www.anaconda.com/understanding-and-improving-condas-performance/

En effet je l'ai fait. C'était un bon article de blog.

Vous proposez essentiellement différents critères d'optimisation.

pas vraiment. Je pense que votre _"contrainte de compatibilité binaire par rapport à une contrainte de version pure et simple"_ indique simplement quelque chose qui me manque probablement. Ce à quoi je m'attendrais, c'est qu'aucun paquet ne devrait avoir python >= 3.7.4 ou == 3.7.4 dans ses métadonnées, c'est toujours == 3.7 (juste vérifié pour scipy, meta.yaml dit python et conda_forge.yml dit max_py_ver: '37' - logique). Donc, introduire un 3.7.4 ne devrait rien faire - le résolveur choisissant 3.7.3 et ne changeant rien d'autre est beaucoup moins cher (et valide selon vos 11 étapes) que de forcer 3.7.4 et de déclencher un chaîne de montées/descentes.

Je suppose que cette partie devient hors sujet pour les plans de déploiement de pip , si heureux de l'emmener ailleurs.

Mon conseil est de passer beaucoup de temps à rendre le solveur très débogable.

+1

Aussi : rendez-le (maintenez-le) aussi réparable que possible. C'est la bonne chose avec pip maintenant, si ça se gâte, on peut généralement faire cd site-packages && rm -rf troublesome_package (éventuellement suivi d'une réinstallation avec --no-deps ) et les choses fonctionnent à nouveau. Les goûts de conda , apt et leurs amis sont beaucoup plus difficiles à réparer de cette façon.

Vous proposez essentiellement différents critères d'optimisation.

Je ne pense pas que vous teniez suffisamment compte du concept de canaux dans votre réflexion. Je ne sais pas à quel point il est pertinent de pip. Certainement beaucoup moins qu'il ne l'est pour conda, mais je ne suis pas sûr que ce soit totalement hors de propos. Les gens peuvent toujours rassembler des packages à partir de plusieurs index à la fois, n'est-ce pas ?

Les packages n'ont pas python >=3.7.4, ni ==3.7.4. La norme dans l'emballage conda est d'avoir une limite supérieure et inférieure. Celles-ci sont généralement déterminées automatiquement par conda-build à l'aide des informations fournies par l'auteur de la recette concernant le nombre d'emplacements de la version à considérer comme une plage compatible. Les packages ont des contraintes telles que> = 3.7.2, <3.8.0a0, la maladresse 0a0 étant là pour tenir compte du fait que les versions préliminaires sont inférieures aux versions .0, et correspondraient donc à une spécification <3.8.0 où les gens ne le font pas s'y attendre vraiment.

Les packages ont également un canal qui leur est associé. Ce canal fait effectivement partie de l'optimisation de la version : https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 - le canal est comme une super-version, une place devant le version majeure du package. Si une résolution ne doit pas changer python, alors la spécification python ne peut pas être python ==3.7 - c'est une plage, et le canal affectera cette plage. Plus précisément, avoir une spécification python ==3.7 et commencer par une installation à partir du canal defaults , puis ajouter le canal conda-forge entraînera beaucoup de désabonnement, car vous avez introduit de nouveaux packages python qui sont plus élevés dans "version" (y compris le canal), et votre spécification python autorise ce changement.

Conda 4.7 a introduit un "gel" beaucoup plus agressif des spécifications, et je suis presque sûr que ce comportement est ce que vous recherchez. C'est quand même assez compliqué. Cela revient à ne geler que les choses qui ne sont pas en conflit avec vos spécifications explicites. La façon dont vous déterminez le « conflit » est la partie la plus difficile. Nous pensons qu'il est préférable de ne pas geler les éléments qui empêcheraient le solveur de fournir à l'utilisateur les packages les plus récents faisant partie du graphique des dépendances de ce package. Ce gel mérite d'être mentionné car il peut être fait sur une base par spécification pour pip d'une manière que conda ne peut pas. Je pense que cela pourrait être une excellente optimisation pour un solveur de backtracking.

Aussi : rendez-le (maintenez-le) aussi réparable que possible. C'est la bonne chose avec pip maintenant, si ça se gâte, on peut généralement faire cd site-packages && rm -rf troublesome_package (éventuellement suivi d'une réinstallation avec --no-deps) et les choses fonctionnent à nouveau. Les goûts de conda, apt et friends sont beaucoup plus difficiles à réparer de cette façon.

Oui, c'est très important. Je pense que pip a fait du bon travail en vendant judicieusement des choses pour qu'il soit plus difficile de casser. C'est très sage, et Conda en tire des leçons. Si vous finissez par utiliser un code compilé, assurez-vous qu'il est lié statiquement ou autrement impossible pour que le chargement dynamique cause des problèmes.

(tangente libsolv : à l'époque où je travaillais pour RH, j'ai saisi https://pypi.org/project/solv/ pour fermer la faille de sécurité "pip install solv" sur Fedora, car le processus de construction de libsolv ne génère pas de sdist ou wheel archive pour le moment, sans parler de le publier sur PyPI. Heureux de discuter avec tous ceux qui pourraient être intéressés à créer ces véritables liaisons de bibliothèque avec une copie groupée de libsolv, plutôt que l'espace réservé inoffensif qu'il est maintenant)

En ce qui concerne mon commentaire de "retrait", je ne veux pas dire "revenir à l'ancienne logique d'installation", je veux dire "fournir une option pour ignorer l'installation de packages qui entraîneraient des violations de contraintes, plutôt que d'échouer à l'ensemble de la demande d'installation".

Yum/DNF propose cela via leur option --skip-broken (dans DNF, cet indicateur est un alias pour --setopt=strict=0 ), et je pense que le résolveur pip devrait offrir une option similaire.

@ncoghlan Ah d'accord. Ça a du sens.

Option de style "ignorer les conflits de version sur ce paquet"

J'avais déjà mentionné que nous ferions cela, c'est pourquoi j'ai été confus par votre commentaire.

Nous sommes alors sur la même page. :)

@ncoghlan a répondu à mon calendrier proposé sur distutils-sig et a dit que cela semblait raisonnable.

@pradyunsg - dans l'attente de votre prochaine mise à jour mensuelle !

J'ai passé un peu de temps à y jeter un coup d'œil et j'ai déposé le numéro 7317.

Je pense que nous y sommes presque en ce qui concerne les abstractions - grâce à beaucoup de travail sur l'interaction de l'index de pip, la résolution des dépendances + la séparation de la logique de construction et un tas de nettoyage général.

Je viens de fermer #7317. Pour autant que je sache, la résolution des dépendances est maintenant découplée (suffisamment) de la logique de construction des métadonnées. La refactorisation de la logique de construction a bien progressé et ce n'est plus un obstacle pour de nouveaux progrès maintenant.

Nous pouvons maintenant commencer à travailler sur l'implémentation des abstractions [resolvelib] dans pip, en nous référant à [passa] et au résolveur de poésie le cas échéant. :)

@pradyunsg Je prévois d'extraire le résolveur de base (basé sur PubGrub) de la base de code Poetry (voir https://github.com/sdispater/poetry/tree/master/poetry/mixology). Il est principalement découplé du reste du code, mais il y a encore des références à des parties internes dont j'ai besoin d'abstraire.

Si vous êtes intéressé à aider avec cela s'il vous plaît faites le moi savoir. L'idée est d'avoir une implémentation autonome de l'algorithme PubGrub qui peut être utilisée par des tiers et qui sera placée dans https://pypi.org/project/mixology/ qui contient actuellement le code de l'ancien résolveur.

@sdispater Certainement ! Je ne sais pas si je peux aider directement (contraintes de temps) mais ce serait génial si vous pouviez dissocier le port PubGrub du reste de la poésie !

Une des choses qui serait vraiment sympa, serait d'avoir une couche d'abstraction cohérente, telle que pip, poésie et pipenv utilisent les mêmes abstractions. En ce moment, nous avons zazo (le mien), mixologie (poésie) et resolvelib (pipenv) - tous définissent une couche d'abstraction quelconque et ils sont légèrement différents mais (ridiculement !) similaires. Si vous êtes ouvert à cela, faites-le nous savoir !

Pour votre information, nous ( @wolfv et l'équipe @QuantStack en général) avons répondu à la RfP pour le résolveur de dépendance pip.

L'approche proposée consiste à adopter la bibliothèque C libsolv et à apporter la prise en charge du format de contraintes de version de pip à libsolv. Nous exposerions la bibliothèque C via de nouvelles liaisons Python.

Libsolv est une bibliothèque endurcie sous-jacente à l'écosystème RPM, et donc déjà utilisée à l'échelle industrielle.

• Libsolv's est distribué sous la licence BSD-3-Clause.
• Libsolv prend en charge plusieurs packages et formats de référentiel, tels que rpm , deb ,
  haiku , conda , arch . Fait important, la variété des formats et des façons d'exprimer
  les contraintes de dépendance montrent qu'il s'agit d'un système enfichable qui devrait pouvoir
  pour s'adapter à la syntaxe de pip pour les contraintes sur les versions de dépendance.
• En utilisant libsolv au lieu du solveur de conda dans le mince wrapper mamba, nous étions
  capable d'améliorer considérablement les performances de conda. (la lenteur de conda dans la résolution des paquets avec de grands canaux était notre principale motivation pour travailler sur mamba).
• Il fonctionne sur plusieurs plates-formes sous Windows, OS X et Linux. ( @wolfv a fait le portage windows de libsolv)
• Il effectue une résolution SAT complète pour trouver des combinaisons de dépendance optimales et s'il ne réussit pas, il renvoie des conseils exploitables pour la résolution des conflits.

L'approche proposée est d'adopter la bibliothèque libsolv C

Il faudrait un repli pour les plateformes que libsolv ne prend pas en charge (par exemple, la prise en charge d'AIX dans pip est en cours d'élaboration, et vous n'avez pas mentionné BSD). Donc libsolv en tant qu'option de performance là où elle est disponible est plausible pour moi, mais nous ne sommes pas vraiment en mesure de l'utiliser uniquement . (Existe-t-il une version Python pure de libsolve, c'est-à-dire quelque chose qui donne les mêmes résultats, juste plus lent ?)

De plus, comment get-pip.py fonctionnerait-il ? Devrions-nous inclure des binaires pour libsolv pour toutes les plates-formes possibles ? Encore une fois, je suppose que non, nous utiliserions une solution de repli en python pur.

L'impossibilité d'utiliser du code C externe est depuis longtemps un ennui pour pip. J'aimerais voir une bonne solution pour cela, mais (a) je ne suis pas sûr qu'il y en ait une (à moins d'une forme de solution d'amorçage "mini-pip" qui nous permet de vendre complètement) et (b) c'est un travail assez important pour que je déteste que le nouveau résolveur en dépende.

Salut @pfmoore

Je pense que la prise en charge supplémentaire de la plate-forme ne devrait pas être si difficile à réaliser car libsolv est un code C assez simple. Je suis à peu près sûr qu'il n'y a pas de version Python pure de libsolv, cependant (ce que je comprends est un inconvénient, mais il n'y a pas non plus de version Python pure de Python, ou la bibliothèque standard Python, donc dans mon esprit, cela ne devrait pas être un bloqueur).

Je pense que pour l'amorçage, on pourrait avoir un pip Python pur qui utilise le mécanisme actuel de résolution, qui installe ensuite la bibliothèque de résolution nécessaire basée sur libsolv. Par exemple, on pourrait épingler le package exact de liaisons Python spécifiques à libsolv + pip et les installer à partir du boostrap-pip comme vous le décrivez. Cela me semble tout à fait faisable, mais vous savez peut-être mieux ce que cela impliquerait ...

Je pense qu'un support de plate-forme supplémentaire ne devrait pas être si difficile à obtenir

Pour être clair, je n'ai aucun intérêt direct dans les plates-formes plus de niche, je pense juste que nous devons être très clairs si nous avons un impact sur les plates-formes sur lesquelles pip est pris en charge (qui pour le moment est essentiellement "tout ce qui peut exécuter Python" ). Il y a aussi la question du déploiement de la façon dont nous livrons une extension C (puisque pip est actuellement livré en tant que roue "universelle", et c'est important pour certains cas d'utilisation comme get-pip.py )

Je pense que pour l'amorçage, on pourrait avoir un pip Python pur qui utilise le mécanisme actuel pour résoudre

J'ai argumenté ci-dessus, et je le répéterai ici, je ne veux pas vraiment avoir à maintenir deux résolveurs en pip indéfiniment.

Mais je ne veux pas être trop négatif à propos de la proposition - je voulais juste signaler certaines des raisons pour lesquelles nous n'autorisons pas actuellement les dépendances sur les extensions C, au cas où vous ne les connaîtriez pas.

La discussion est probablement mieux adaptée ailleurs, et pourrait être totalement redondante quand/si plus de détails sont révélés, mais je veux vraiment poser mes questions maintenant.

D'après ce que j'ai compris, libsolv utilise un solveur entièrement SAT pour la résolution des dépendances et nécessite le chargement des informations de dépendance avant de commencer à résoudre. Mais PyPI stocke désormais les métadonnées de dépendance par package. Même si vous ignorez la nature dépendante de l'exécution de setup.py , il serait difficile de récupérer efficacement les informations nécessaires au solveur SAT.

Comment comptez-vous gérer ce problème ? Prévoyez-vous d'implémenter une infrastructure (et de proposer des spécifications supplémentaires pour les implémentations de référentiels tiers) pour générer des fichiers .solv lorsque les packages sont téléchargés ? Ou avez-vous des stratégies dans vos manches pour générer des données résolubles appropriées au fur et à mesure que le solveur avance, et peut-être mettre en œuvre un retour en arrière à mesure que de nouvelles données de dépendance arrivent ?

Je ne suis au courant d'aucun travail existant à cet égard, et la plupart des ressources que je peux trouver suggèrent que le paysage de l'emballage Python a besoin d'autre chose/plus qu'un solveur SAT simple. Je suis donc très intéressé par toutes les possibilités ici.

Ces fichiers .solv ne servent qu'à la mise en cache, libsolv n'en a pas besoin pour la résolution. Mais je suis d'accord que la nature dynamique des dépendances de PyPI rend difficile l'utilisation d'un solveur SAT.

(Voir https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit pour plus d'informations)

(Notez qu'un solveur SAT n'est qu'un solveur de retour en arrière qui fait également l'apprentissage des clauses s'il se heurte à un conflit, donc je pense qu'il est possible d'utiliser un solveur SAT pour PyPI. Mais il doit s'agir d'un solveur qui permet d'ajouter dynamiquement des clauses lors de la résolution.)

Les solveurs Sat ont aujourd'hui des capacités importantes, notamment des ajouts dynamiques, des redémarrages, des retours en arrière, des redémarrages aléatoires, etc. un solveur basé sur C.

Je suis à l'aéroport en ce moment donc je ne peux pas répondre aux points qui ont été soulevés pour le moment mais... Je suis sûr que nous ne devrions pas discuter des choix/compromis techniques ici -- c'est plus axé sur comment nous communiquons et gérons le déploiement par rapport à ce que nous déployons. :)

J'ai déposé # 7406 pour une discussion plus approfondie sur les compromis techniques - @sdispater , @techalchemy , @uranusjr , @wolfv J'apprécierais si nous pouvions avoir une discussion plus approfondie sur les différents choix pour la conception du résolveur.

Pour définir les attentes tôt, je vais voyager pendant les 2 prochaines semaines et j'espère pouvoir rattraper toutes les discussions le ~ 9 décembre.

Mise à jour de l'état : la PSF a pu obtenir un financement du support open source de Mozilla et de l'initiative Chan Zuckerberg pour embaucher des sous-traitants pour travailler sur le résolveur de pip et les problèmes d'expérience utilisateur associés . Vous pouvez voir notre feuille de route (que j'ai besoin de peaufiner) et les articles de blog, de forum et de liste de diffusion et les notes des réunions récentes pour vous tenir au courant. Je publierai bientôt quelque chose à ce sujet sur distutils-sig et sur le forum Packaging sur Python's Discourse instance .

Notre objectif est que la fonction de résolution de pip soit préparée pour être publiée dans pip 20.2 en juillet. (Selon la cadence de publication trimestrielle pour pip, des difficultés imprévues peuvent retarder jusqu'à 20,3 au prochain trimestre.)

@uranusjr :

D'après ce que j'ai compris, libsolv utilise un solveur entièrement SAT pour la résolution des dépendances et nécessite le chargement des informations de dépendance avant de commencer à résoudre. Mais PyPI stocke désormais les métadonnées de dépendance par package. Même si vous ignorez la nature dépendante de l'exécution de setup.py, il serait difficile de récupérer efficacement les informations nécessaires au solveur SAT.

Le prototype de commande pip resolve dans #7819 utilise deux techniques pour obtenir ces informations de manière performante (voir ce problème pour plus de détails) :

1. > Extraire le contenu du fichier METADATA d'une url pour une roue sans télécharger la roue du tout.
2. > Mise en cache du résultat de chaque appel self._resolve_one() dans un fichier json persistant.

La technique utilisée pour (1) est capable de convertir très rapidement une URL de roue en une liste de chaînes d'exigences dont elle dépend, tout en ne téléchargeant que quelques Ko du contenu de la roue elle-même. Le prototype dans #7819 garantit ensuite que req.populate_link() est appelé sur chacune des exigences dépendantes renvoyées par self._resolve_one() et stocke le mappage de (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] dans un fichier de cache json persistant. (1) obtient de nouvelles informations rapidement, (2) rend les anciennes informations plus rapides à interroger.

Bien que je ne sois pas encore familier avec libsolv, je pense que les entrées de ce mappage de l'URL d'exigence aux dépendances et leurs URL peuvent être exactement l'entrée atomique requise par un solveur SAT. Comme démontré dans # 7189, le fichier de cache de dépendances json persistant a fait que les invocations pip resolve deviennent complètement no-ops après la première exécution, prenant 800 à 900 ms sur la ligne de commande à partir de là. Si les techniques de (1) et (2) sont utilisées, je pense qu'il est possible de laisser un solveur SAT s'exécuter jusqu'à la fin à chaque fois que pip est invoqué sans attendre un temps incroyablement long. Il ne serait probablement pas trop difficile d'essayer de pirater libsolv au-dessus du prototype dans # 7189 pour rendre ce nombre plus concret.

@techalchemy :

Les solveurs Sat ont aujourd'hui des capacités importantes, notamment des ajouts dynamiques, des redémarrages, des retours en arrière, des redémarrages aléatoires, etc. un solveur basé sur C.

pants avait autrefois du code qui facilitait l'exposition d'un compilateur et d'un éditeur de liens à un projet basé sur setup.py (#6273), mais nous l'avons supprimé plus tard (voir #7016) en faveur de la possibilité de construire C/C++ dans un pantalon sans utiliser setup.py , ce qui était approprié pour notre cas d'utilisation à l'intérieur de Twitter qui n'avait besoin que de créer une bibliothèque partagée pour les opérateurs personnalisés TensorFlow . Nous hébergeons des binaires prédéfinis pour les archives GCC et binutils liées statiquement sur notre s3 pour OSX et Linux (voir https://github.com/pantsbuild/binaries/) afin que les utilisateurs de pantalons n'aient pas à installer autre chose que python et un JDK d'utiliser un pantalon du tout.

Je serais intéressé à aider à réfléchir et/ou à développer tout type d'outils pour la construction portable de C et C++ qui pourrait permettre à pip de dépendre de manière fiable de libsolv sur toutes les plates-formes prises en charge.

@cosmicexplorer

pantalon avait l'habitude d'avoir du code qui facilitait l'exposition d'un compilateur et d'un éditeur de liens à un projet basé sur setup.py (#6273), mais nous l'avons supprimé plus tard (voir #7016) en faveur de la possibilité de construire C/C++ dans un pantalon sans utiliser setup.py, ce qui était approprié pour notre cas d'utilisation à l'intérieur de Twitter, qui n'avait besoin que de créer une bibliothèque partagée pour les opérateurs personnalisés TensorFlow. Nous hébergeons des binaires préconstruits pour les archives GCC et binutils liées statiquement sur notre s3 pour OSX et Linux (voir pantsbuild/binaries) afin que les utilisateurs de pants n'aient pas à installer autre chose que python et un JDK pour utiliser pants.

Le travail du compilateur/éditeur de liens est très intéressant ! Il y a aussi une discussion sur le découplage du compilateur de setup.py (ou d'un backend de construction PEP 517 en général). Ce n'est pas vraiment lié au résolveur (du moins pas directement), mais cela pourrait vous intéresser : https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- conduite-c-compilateurs/2591

@cosmicexplorer

Je serais intéressé à aider à réfléchir et/ou à développer tout type d'outils pour la construction portable de C et C++ qui pourrait permettre à pip de dépendre de manière fiable de libsolv sur toutes les plates-formes prises en charge.

@wolfv et moi-même avons examiné cela pour créer des parties de la pile du gestionnaire de packages DNF sur toutes les principales plates-formes prises en charge pour mamba et mon travail personnel avec DNF. À ce stade, libsolv est désormais capable d'être conçu pour Windows, Linux, macOS, BSD, Haiku OS, et je suis vaguement conscient qu'il est installé sur divers systèmes UNIX dans le cadre de l'utilisation de DNF sous UNIX. Je sais que @dralley a également mis à disposition des roues binaires solv pour ~les principales plates-formes prises en charge par PyPI~ Linux en utilisant manylinux2014 sur PyPI .

Nous avons maintenant pip 20.1b1, une version bêta qui inclut une version très précoce (alpha) du nouveau résolveur (voir # 8099 pour le contexte à ce sujet, et une enquête où les gens peuvent donner leur avis). Voici l'annonce . Et https://github.com/pypa/pip/issues/7951#issuecomment -617851381 répertorie certains endroits où nous avons annoncé la version bêta jusqu'à présent.

pip 20.1 est maintenant disponible et inclut la version alpha du résolveur.

Nous discutons de la publication d'une autre version de pip en mai, une qui inclut une version alpha plus avancée du résolveur. Et nous déterminons quand publier la version bêta du nouveau résolveur et faire une poussée "veuillez tester ceci".

Nous avons rencontré des retards alors que nous cherchions à comprendre # 8371, comment mieux afficher certains messages d'erreur et gérer un tas d'autres trucs épineux; voir https://github.com/pypa/pip/projects/6 et https://github.com/pypa/pip/projects/5 pour en savoir plus sur nos progrès. # 8206 est une discussion sur la prochaine version bêta, pip 20.2b2, que j'espère que nous pourrons publier d'ici la fin juin.

J'ai posté notre rapport de mi-année sur le blog PSF . Une chose clé à savoir : plus tard ce mois-ci, nous publierons pip 20.2 qui aura une version bêta du nouveau résolveur de dépendances (pip 20.1 avait une version alpha) disponible via un drapeau facultatif " --use-feature=2020-resolver ". Nous ferons beaucoup de publicité pour le pip 20.2 et demanderons à de nombreux utilisateurs de mettre le nouveau résolveur à l'épreuve.

Par # 8511, nous avons maintenant publié pip 20.2 . Cette version inclut la version bêta du résolveur de dépendances de nouvelle génération . Il est nettement plus strict et plus cohérent lorsqu'il reçoit des instructions incompatibles et réduit la prise en charge de certains types de fichiers de contraintes, de sorte que certaines solutions de contournement et flux de travail peuvent être interrompus. Veuillez le tester avec le drapeau --use-feature=2020-resolver . Veuillez consulter notre guide pour savoir comment tester et migrer, et comment signaler des problèmes . Le nouveau résolveur de dépendances est désactivé par défaut car il n'est pas encore prêt pour une utilisation quotidienne .

Nous prévoyons de publier la prochaine version trimestrielle de pip, 20.3, en octobre 2020. Nous nous préparons à modifier le comportement de résolution des dépendances par défaut et à faire du nouveau résolveur la valeur par défaut dans pip 20.3.

Veuillez faire passer le mot en pointant vers cet article de blog - faites passer le mot sur Hacker News, Reddit, Twitter, Facebook, Dev.to, Telegram, les réponses pertinentes à Stack Overflow et vos Slacks et Discords préférés. La plupart des personnes que cela affectera ne suivent pas les nouvelles des développeurs spécifiques à Python. Aidez-les à se tenir au courant avant octobre et aidez-nous à obtenir leurs rapports de bugs.

(Copiant ma note de #988.)

@zooba a demandé :

Pensez-vous que nous devrions mettre à jour la version de pip fournie avec Python 3.9 à ce stade (pour le premier RC) ?

De même, est-il nécessaire de mettre à jour Python 3.8 pour sa prochaine version ?

Mon hypothèse est que, oui, après la publication du correctif au début de la semaine prochaine, oui, mais @pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufft qu'en pensez-vous ?

Désolé, cliquez sur le message trop tôt. Mon raisonnement est que le regroupement de pip 20.2 permettra aux développeurs expérimentés de tester facilement le nouveau résolveur de dépendances tout en testant les dernières versions de Python. Mais je ne sais pas combien de travail il faut pour mettre à jour cette version groupée, ni à quelle fréquence vous voulez le faire.

Pareil ici, il serait bien d'inclure un 20.2.x dans le 3.9 pour un accès plus facile au nouveau résolveur.

Qu'est-ce que tu penses?

Vous avez raison, c'est le plan. :)

OK, répondu sur python-dev - oui, la version de pip fournie dans Python 3.8 et 3.9 doit être mise à jour vers 20.2.x.

Par ailleurs, sur la publicité, je noterai ici quelques travaux en cours :

Au cours des 6 à 8 prochaines semaines, je ferai pression pour obtenir une large publicité afin que les utilisateurs essaient d'utiliser le nouveau pip. Je soupçonne que le problème ne sera pas tant "ce paquet individuel ne s'installera pas" ; il s'agira de conflits inattendus entre des packages particuliers, peut-être dépendants de l'environnement et de fichiers de contraintes particuliers. Nous essayons d'obtenir des commentaires précoces via l' enquête afin que nous puissions ensuite corriger les bogues, mettre en place des tests plus automatisés, etc. : le problème TensorFlow/numpy/scipy dans https://github.com/pypa/pip/issues/8076#issuecomment-666493069 ).

Peu importe les efforts que nous déployons pour cela, il y aura des utilisateurs confrontés à des incohérences qui se heurteront à la 20.3, et ils seront frustrés, confus et blessés, ce qui entraînera une charge de support pour nous et pour tous leurs amonts. Nous visons à réduire cela en invitant les utilisateurs à tester et en attirant l'attention des amonts.

Je prévois donc de contacter et de tirer parti des groupes qui prêtent attention à leurs propres coins spécifiques à un domaine particulier - les scientifiques des données, les enseignants, les artistes, les spécialistes DevOps, etc.

Je suppose qu'une façon d'attirer leur attention est via les packages spécifiques sur lesquels ils s'appuient.

Hier, j'ai parcouru certaines listes de packages largement utilisés et j'ai envoyé manuellement un e-mail à quelques personnes et créé des problèmes sur quelques référentiels pour leur suggérer de demander à leurs utilisateurs de tester avec la version bêta du nouveau résolveur, de lancer le bal et d'essayer certains formulation/approches pour obtenir plus de publicité et de tests. Cela a conduit à la confusion dans au moins un cas - voir https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739 - et une fois la version 20.2 corrigée des bogues sortie, je serai un peu plus systématique et plus clair sur

• pourquoi nous tendons la main
• qui nous avons choisi de contacter/quand (un lien vers une stratégie de médias publics aidera)
• pourquoi nous ne pouvons pas utiliser les tests automatisés pour trouver ces problèmes nous-mêmes

Nous avons reçu un peu d'attention sur Twitter ( 1 , 2 ) et Reddit (quelqu'un veut-il répondre à cette question sur le financement de PyPA ?).

@zooba a écrit (concernant le regroupement):

Merci. Il semble que nous puissions le faire plus tard cette semaine et faire la prochaine série de versions. S'il vous plaît, faites-nous savoir dès que possible si quelque chose se produit et que vous ne voudriez pas être libéré.

Je trouve que le --use-feature=2020-resolver pour moi résout généralement plus de problèmes qu'il n'en cause.

est-il trop tard pour proposer un premier déploiement via :

pseudo-code 20.3 proposé

try:
    _2020_resolver()
except:
    legacy_resolver()

ce qui voudrait dire au moins pour mes projets qu'ils passeraient tous sans modification

suite à cela, une fois que le résolveur hérité est désactivé par défaut, je peux avoir pendant un certain temps des projets qui fonctionnent sous le résolveur 2020 et d'autres non sous le résolveur hérité, j'aimerais pouvoir définir un indicateur pour activer une solution de secours :

pseudo-code 20.4 proposé

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

Nous prévoyons de déployer 20.3 plus tard ce mois-ci. Nous prévoyons que cela nécessitera un grand nombre d'assistance aux utilisateurs, car des utilisateurs confus nous poseront des questions.

@di s'est porté volontaire pour aider à rassembler des volontaires pour aider à la première réponse. Ces bénévoles répondront aux questions et aideront à la charge du support utilisateur une fois que le nouveau pip sortira - sur Twitter, StackOverflow et GitHub - et signalera les bogues réels à l'attention de l'équipe de mainteneur/contributeur.

Dustin, je pense que vous avez un plan approximatif sur la façon dont cela fonctionnerait - cela vous dérangerait-il de le publier ici et ensuite j'obtiendrai un consensus des autres responsables de pip? Merci profondément.

Voici mon plan approximatif :

• Lancer une discussion sur discuter.python.org en demandant de l'aide
• Dirigez les gens vers un canal Slack qui pourrait servir de canal de communication entre tout le monde
• Commencer un document décrivant quelques FAQ et nos réponses
• Inclure un arbre de décision pour un nouveau problème -> problème trié
• Partagez ceci avec la chaîne une fois que nous aurons une date de sortie connue
• Essayez de programmer approximativement les bénévoles pour qu'ils soient en ligne et triés dans les jours suivant la publication

Merci, @di. Nous attendons jusqu'à demain pour obtenir les OK des autres mainteneurs. Et nous visons à publier le pip 20.3 le mercredi ou le jeudi 28 ou 29 octobre.

@di Je vois que votre plan est approuvé. S'il vous plaît allez-y!

@di prévient d' un éventuel retard dans la publication .

Au cas où je ne serais pas disponible lorsque nous serons en mesure de publier le 20.3 (qui, nous l'espérons, sera la semaine prochaine), voici un plan de publicité .

Comme je l'ai expliqué dans un autre commentaire , nous avons décidé de retarder légèrement la sortie, en raison de certains problèmes d'IC ​​qui sont apparus et de certains facteurs externes.

Lors de la réunion d'équipe d'aujourd'hui, nous avons convenu que la version 20.3 serait probablement demain ou vendredi. Vous pouvez suivre #8936 pour en savoir plus.

Je n'ai pas fait autant de sensibilisation par paquet que je l'avais suggéré dans un commentaire précédent. Mais cela ne signifie pas que nous n'avons fait aucune sensibilisation. Certaines des activités de sensibilisation que nous avons effectuées (dont certaines sont cataloguées dans # 8511 ou cette page wiki ):

• Podcasts : Podcast.__init__ , Test et code , FLOSS hebdomadaire , Parcours des développeurs de logiciels , Real Python
• Un tas de tweets
• Une courte vidéo YouTube sur les changements
• Courriels aux sponsors PyCon, PSF et PyPI de leur contact de sponsoring PSF, leur demandant d'informer leurs départements d'ingénierie des changements à venir
• Courriel à pypi-announce et listes similaires
• Articles de blog comme celui-ci
• Courriel aux technologies civiques et aux groupes/groupes de réflexion similaires

Au cours des derniers mois, nous avons reçu un flux constant de nouveaux problèmes de personnes testant le nouveau résolveur en 20.2 et la version bêta 20.3, pip 20.3b1 . Ces rapports nous ont aidés à améliorer le résolveur, à corriger des bogues et à améliorer l'UX de sa sortie. Nous avons également considérablement amélioré le guide de l'utilisateur "Quoi de neuf ?" , en partie en réponse aux commentaires sur la version bêta.

Voici mon plan approximatif :

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di Je reconnais que l'incertitude constante et les retards vous ont probablement empêché de faire la planification. La nouvelle date de sortie est demain, lundi 30 novembre. Si vous avez maintenant un fil de discussion et un arbre de décision à partager, n'hésitez pas à les partager !

pip 20.3 est sorti, et il a le nouveau résolveur par défaut ! Voici l'annonce de sortie sur le blog PSF : https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html