Pipenv: Mettre à jour une seule dépendance verrouillée

Cela pourrait également être utile pour pipenv install , car je souhaite parfois installer une nouvelle dépendance sans en mettre à jour les autres.

Il y a une petite chose à prendre en compte ici: la modification d'une seule dépendance peut modifier l'ensemble des exigences.
Ex: la mise foo jour de bar vers> = 2.0 (alors qu'il était <2.0 auparavant), et ainsi de suite.

Je sais que dans le contexte de pip-tools lui-même (à partir duquel pipenv prend son algorithme de résolution de dépendance), l'exécution de la résolution de dépendance ne "met à jour" que les packages requis lors du "re-verrouillage" s'il y un fichier de verrouillage existant. Il le fait en vérifiant si les broches existantes dans le fichier de verrouillage sont des candidats valides en premier lors de la sélection d'un candidat dans la résolution. pipenv pourrait probablement faire la même chose.

Je pense que c'est une idée raisonnable. Sinon, si vous ne voulez mettre à jour qu'une seule dépendance, pipenv devrait avoir un mode à bloquer si la modification d'une dépendance entraîne d'autres changements, sinon vous perdriez la garantie d'un environnement valide.

J'espère que ça aide!

En effet, c'est ce que je voulais dire par:

Cela générerait un Pipfile.lock avec des mises à jour uniquement pour my-awesome-dep et ses dépendances.

D'accord à 100% - et j'irai un peu plus loin: cela devrait être la valeur par défaut.

Autrement dit, pipenv install foo ne devrait jamais toucher à autre chose que foo et ses dépendances. Et pipenv lock ne devrait certainement jamais mettre à jour quoi que ce soit - il devrait simplement verrouiller ce qui est déjà installé.

AFAICT, voici comment fonctionnent npm , yarn , gem , etc. cela n'a aucun sens d'avoir un fichier de verrouillage qui ne verrouille pas réellement les paquets, mais fait confiance aux auteurs de paquets pour ne pas casser des choses dans les versions de correctifs, et donc les met à jour sans qu'on leur demande. Je peux voir l'utilisation d'autoriser les mises à niveau, mais cela devrait être opt-in, car c'est plus surprenant que de ne pas les mettre à niveau.

Je m'excuse si je détourne ce problème pour autre chose, mais comme c'est si étroitement lié à un problème que j'allais créer, j'ai pensé que je commencerais la conversation ici. N'hésitez pas à me dire que je devrais en faire un nouveau.

Je viens de trouver ce problème connexe également: https://github.com/kennethreitz/pipenv/issues/418

Pouvoir spécifier pipenv install --upgrade-strategy=only-if-needed semble être ce que je recherche, bien que bien sûr, comme je l'ai mentionné, je pense que cela devrait être la valeur par défaut, comme c'est le cas dans pip 10. Mais pouvoir le spécifier de manière semi-permanente via env var serait quelque chose, de toute façon.

Je serais surpris si ce changement casse le flux de travail de quelqu'un ( derniers mots célèbres ), car il est plus conservateur que --upgrade-strategy=eager .

J'ai essayé de contourner ce problème en définissant export PIP_UPGRADE_STRATEGY=only-if-needed dans ma configuration de shell. Cela ne fonctionne pas et pipenv lock présente ces comportements surprenants:

1. Il «met à jour» les paquets qui n'ont pas besoin d'être mis à jour (mais ...)
2. En fait, il ne met pas à niveau les versions installées! ie pip freeze et Pipfile.lock montrent des versions différentes!

Je suppose que pipenv délègue à pip pour l'installation, et pip respecte ses paramètres de variable d'environnement, mais pas pipenv lock .

@ k4nar Que se passe-t-il maintenant que vous trouvez indésirable? Parce que si vous mettez à niveau une dépendance qui a des exigences en cascade, cela aura évidemment des conséquences pour d'autres dépendances. Proposez-vous une sorte de logique de résolution pour déterminer la version la plus récente d'un package spécifique _dans le contexte du fichier de verrouillage actuel_? J'hésite à encourager trop de hacks à la logique de résolution, qui est déjà compliquée et difficile à déboguer.

@brettdh Je pense que je peux faire la lumière parce que vous avez la plupart des pièces. pipenv lock n'installe rien, et il ne le prétend pas. Il génère uniquement le fichier de verrouillage en fonction de votre environnement hôte, de la version de python et d'un Pipfile fourni. Si vous manipulez votre environnement d'une autre manière ou si vous utilisez pip directement / manipulez les paramètres de pip en dehors de pipenv / n'utilisez pas pipenv run ou n'utilisez pas pip freeze dans un sous-shell pipenv, c'est assez facile pour un fichier de verrouillage désynchronisé de pip freeze . Les deux ne sont pas vraiment liés.

Pour être clair:

1. Pipfile.lock est une résolution de dépendance strictement épinglée utilisant le résolveur pip-tools basé sur le Pipfile
2. Si vous souhaitez conserver des épingles strictes de tout tout en mettant à niveau un seul paquet, je pense que vous pouvez le faire en épinglant strictement tout dans votre Pipfile sauf pour la seule chose que vous souhaitez mettre à niveau (corrigez-moi si je me trompe @vphilippon)

En ce qui concerne votre lockfile et pip freeze désaccord, je devrais en savoir plus, mais je pense que nous avons un problème ouvert concernant notre résolveur de lockfile lors de l'utilisation de versions non système de python pour résoudre.

@techalchemy : Si j'ai un Pipfile.lock avec A, B et C où B est une dépendance de A, j'aimerais pouvoir mettre à jour A et B sans mettre à jour C, ou C sans mettre à jour A et B.
Encore une fois, bien sûr, je peux épingler toutes mes dépendances et leurs dépendances dans mon Pipfile pour ce faire, mais ce serait un fardeau à maintenir (comme la plupart des requirements.txt ).

Je suis d'accord avec tout ce que @ k4nar a écrit. Bien sûr, je pourrais même simplement épingler
tout dans requirements.txt et ne pas utiliser pipenv. Le point de pipenv est
pour avoir un outil qui fait ça (et les trucs virtualenv, bien sûr)
plus simple à gérer; c'est-à-dire que tous les packages sont verrouillés par défaut sur une version
qui fonctionne, mais il devrait être simple de mettre à niveau une sélection
peu (sans mettre à niveau les autres de manière inattendue).
Le jeu.26 oct.2017 à 04:28 Yannick PÉROUX [email protected]
a écrit:

@techalchemy https://github.com/techalchemy : Si j'ai un Pipfile.lock
avec A, B et C où B est une dépendance de A, j'aimerais pouvoir
mettre à jour A et B sans mettre à jour C, ou C sans mettre à jour A et B.
Encore une fois, bien sûr, je peux épingler toutes mes dépendances et leurs dépendances dans mon
Pipfile pour ce faire, mais ce serait un fardeau à maintenir (comme
la plupart des requirements.txt sont).

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
.

Hm, je vois ce que vous dites. La prémisse de passer un paramètre à pip n'est pas ce qui m'inquiète, c'est la résolution avec pip-tools qui me préoccupe. À quoi ressemble ce comportement en ce moment?

@techalchemy J'ai mentionné la différence pip freeze comme un raccourci pour «les versions de paquet que pipenv install installe diffèrent des versions de paquet que pipenv lock enregistre à Pipfile.lock .

Certes, cela ne se produit que lorsque j'ai changé les arguments par défaut de pip via la variable d'environnement; Je faisais juste remarquer qu'il était surprenant que pipenv ait délégué à pip pour l'installation mais pas pour le verrouillage de version; c'est-à-dire qu'au lieu de verrouiller ce qui est installé, il verrouille ce qu'il pense devoir être installé, potentiellement avec des mises à niveau non demandées.

Pourriez-vous clarifier un peu votre question? Je pense que "résoudre avec pip-tools" fait référence à ce que fait pipenv lock , et la raison pour laquelle il n'est pas affecté lorsque je définis les valeurs par défaut de pip? Et pourriez-vous être plus précis sur ce que vous entendez par «ce comportement»?

@brettdh Le mécanisme de verrouillage inclut une notion de "résolution de dépendance" qui n'existe pas dans pip . Il est géré par pip-tools (ou plutôt, une version corrigée de celui-ci, intégrée de manière spéciale par pipenv qui apporte quelques différences avec l'outil d'origine). En bref, le mécanisme de verrouillage lit le Pipfile et effectue une résolution complète des dépendances pour sélectionner un ensemble complet de packages qui répondra à toutes les contraintes définies par les packages requis et leurs dépendances .

@techalchemy

[...] c'est la résolution avec pip-tools qui me préoccupe.

Je ne sais pas comment ces --upgrade-strategy affecteront pip-tools , car cela fonctionne sur certains internes de bas niveau de pip . J'ai le sentiment que cela ne donnerait pas le résultat escompté, car ces options tiennent compte de ce qui est installé, et ce n'est pas ce qui est traité dans ce mécanisme. Mais nous avons une autre approche à cela dans pip-tools qui pourrait être faite ici.

Le comportement "original" de pip-tools est qu'il ne met à jour que ce qui est nécessaire dans le fichier de verrouillage (dans son contexte, c'est le requirements.txt), mais cela a été "perdu" dans la façon dont le résolveur était intégré dans pipenv . Laissez-moi vous expliquer pourquoi.

Rappelant mon CV du fonctionnement de pip-tools : https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
Vous vous souvenez de la partie «sélectionner un candidat»? Cela se fait en interrogeant l'objet Repository .
Dans pipenv , nous configurons directement un PyPIRepository pour le Resolver , mais pip-tools fait autre chose, il utilise un objet LocalRequirementsRepository , qui conserve les broches existantes du requirements.txt (si trouvé), et les "fallbacks" sur PyPIRepository .

Ainsi, dans pip-tools , ce qui suit se produit lors de la sélection d'un candidat:

1. Requête LocalRequirementsRepository pour un candidat qui correspond à foobar>=1.0,<2.0 .
2. Vérifiez si une broche existante répond à ces exigences:
   
   
   
   • Si oui, renvoyez cette épingle comme candidat.
   
   
   • Sinon, interrogez le proxied_repository ( PyPIRepository ) pour le candidat.
   
   
3. Utiliser le candidat retourné

En fait, cela signifie que les broches existantes reçoivent une «priorité» en tant que candidat à essayer en premier.

Mais dans pipenv , actuellement, il suffit de:

1. Requête PyPIRepository (directement) pour un candidat qui correspond à foobar>=1.0,<2.0 .
2. Utilisez le candidat retourné.

Donc, je pense que le même comportement pour le verrouillage dans pipenv pourrait être fait en analysant le Pipfile.lock pour obtenir les broches existantes et utiliser un LocalRequirementsRepository , comme pip-tools fait dans sa commande pip-compile .

@vphilippon avez-vous une idée de la difficulté de mise en œuvre à ce sujet?

@techalchemy

• Analyser le Pipfile.lock pour extraire les broches existantes: Je n'ai pas regardé cela. Dépend de la façon dont les choses sont structurées en pipenv . Nous avons besoin d'un ensemble de InstallRequirements qui représente les broches dans le Pipfile.lock .
• Utilisation de LocalRequirementsRepository : Assez simple: changez notre PyPIRepository actuel pour un LocalRequirementsRepository .

Mais, en regardant cela et en suivant les commentaires de @brettdh , je réalise quelques choses:

1. Le comportement par défaut actuel pipenv install ne correspond pas au comportement pipenv lock . Faire pipenv install requests seul ne mettra pas à jour requests si une nouvelle version sort (un peu comme directement pip install ). Cependant, faire pipenv lock mettra à jour le Pipfile.lock avec la dernière version de requests qui correspond au spécificateur Pipfile et aux contraintes de dépendance.
   Il y a 2 façons principales de voir cela:
   
   
   
   • A) Le Pipfile.lock doit rester aussi stable que possible par défaut, ne changer les broches que si nécessaire, afin de rester comme l'environnement actuel, et ne changer que dans le cas où nous changeons l'environnement.
   
   
   • B) Le Pipfile.lock devrait obtenir les dernières versions qui respectent les contraintes / dépendances de l'environnement afin de bénéficier librement des plages ouvertes dans les dépendances Pipfile et lib, permettant d'acquérir en continu de nouvelles versions compatibles dans votre environnement. Vous pouvez ensuite exécuter pipenv update pour bénéficier du nouveau verrou.
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. Même si nous utilisons LocalRequirementsRepository pour éviter de mettre à jour les broches existantes correctes, et finissons par aligner les comportements par défaut, nous devons alors adresser l'équivalent de --upgrade et --upgrade-strategy pour la partie de verrouillage . Actuellement, la définition d'une variable d'environnement (comme PIP_UPGRADE et PIP_UPGRADE_STRATEGY ) affectera le comportement de pipenv install , mais n'affectera pas pipenv lock , car cela n'affectera pas le comportement de pip-tools (je l'ai confirmé, car je n'étais pas sûr au début).
   Sinon, il n'y aura aucun moyen de mettre à jour l'environnement sans supprimer le Pipfile.lock (semble maladroit, et "tout ou rien") ou exiger une version plus récente (je veux dire faire un pipenv install requests>2.18.4 explicite, ce qui vous oblige à savoir qu'une nouvelle version est sortie, et change le spécificateur dans le Pipfile lui-même, augmentant la limite inférieure), ce qui est faux. Comme l '"original pip-tools " ne se reporte pas à pip pour gérer cela (car il n'est pas lié à ce qui est actuellement installé), il offre une option pour spécifier les dépendances à mettre à jour dans le lockfile, et supprimez simplement les broches de ces packages (ou de tous) de la liste existing_pins, pour revenir à l'interrogation de PyPI. Je ne sais pas comment nous pouvons faire correspondre la notion de "--upgrade-strategy" avec cela.

@techalchemy
Donc, alors que je disais qu'il était assez facile de simplement "aligner le comportement par défaut", je me rends compte maintenant que cela causerait un problème majeur pour pouvoir mettre à jour les packages (comme dans: il suffit de récupérer la dernière version qui correspond à mes contraintes actuelles) .

S'il y a quelque chose de peu clair, demandez-le, beaucoup de modifications ont été effectuées lors de l'écriture de ceci.

(La résolution des dépendances n'est pas facile. La résolution des dépendances bonne et pratique est encore pire 😄)

@vphilippon c'est exactement ce que je voulais dire. Garder les choses que pip installe en synchronisation avec les choses que pip-tools résout n'est pas trivial à moins que vous ne conduisiez le processus en arrière, en utilisant le fichier de verrouillage résolu pour faire l'installation. Je suis à peu près sûr que c'est pour cela que les choses ont été conçues comme elles l'étaient.

B) Le Pipfile.lock devrait obtenir les dernières versions qui respectent les contraintes / dépendances de l'environnement afin de bénéficier librement des plages ouvertes dans les dépendances Pipfile et lib, permettant d'acquérir en permanence de nouvelles versions compatibles dans votre environnement. Vous pouvez ensuite exécuter pipenv update pour bénéficier du nouveau verrou.

Ce workflow peut éventuellement fonctionner avec la configuration actuelle. Vous pouvez utiliser pipenv lock pour générer un fichier de verrouillage, mais pipenv update réinstallera tout l'environnement. Je suis presque sûr que nous pouvons utiliser l'un de nos différents formats de sortie pour résoudre le graphe de dépendance (nous avons déjà un format json comme vous le savez) et ne réinstaller que les choses qui ne sont pas alignées sur le fichier de verrouillage. Cela pourrait être plus judicieux, mais je serais curieux de savoir ce que @nateprewitt ou @erinxocon apportent avant de prendre une décision

@vphilippon Tout à fait d'accord que A et B sont des flux de travail souhaitables dans différentes situations. Certains de vos phrasés autour de B m'ont un peu dérouté, cependant, semblant dire que pipenv lock pourrait résulter en un fichier de verrouillage qui ne correspond pas réellement à l'environnement - j'ai particulièrement entendu cela en ce qu'il faudrait "exécuter pipenv update pour bénéficier du nouveau verrou "- comme si le verrou était" en avance "sur l'environnement plutôt que de le faire correspondre.

Que vous soyez dans un flux de travail A ou un flux de travail B, certaines choses me semblent constantes, et je pense que cela correspond également à ce que @techalchemy dit:

• Le résultat de pipenv lock doit toujours être un fichier de verrouillage qui correspond à l'environnement.
• Le résultat de pipenv install doit toujours être un environnement qui correspond au fichier de verrouillage.

J'ignore les détails de l'implémentation, mais c'est un peu le comportement de base que j'attends d'un gestionnaire de packages avec une fonctionnalité de fichier de verrouillage.

Exécuter pipenv update périodiquement vous permet de rester en mode B tant que vous voulez que tout soit frais, et avoir la possibilité de pipenv install --upgrade requests permettrait des mises à jour spécifiques d'un paquet et de ses dépendances, sans affecter les paquets qui n'ont pas besoin d'être mis à niveau inutilement.

Est-ce que je manque des cas d'utilisation? Je peux penser à des optimisations pour B - par exemple un drapeau ou une var env qui lui dit de toujours se mettre à jour avec impatience - mais je pense que cela couvre les bases. Je sais aussi que je rechappe le terrain que vous avez déjà parcouru; il est juste utile pour moi de m'assurer de bien comprendre de quoi vous parlez. :)

Certains de vos phrasés autour de B m'ont un peu dérouté, cependant, semblant dire que le verrou pipenv pourrait entraîner un fichier de verrouillage qui ne correspond pas réellement à l'environnement

@brettdh c'est correct - le résolveur pip-tools nous utilisons pour générer Pipfile.lock ne demande pas à virtualenv une liste des paquets installés. Au lieu de cela, il compile une liste de packages qui répondent aux critères spécifiés dans la liste des broches à partir du Pipfile . Parce que le résolveur lui-même fonctionne en utilisant le système ou l'installation externe de python / pipenv / pip-tools, nous faisons une putain de merde suprême pour le convaincre de résoudre les paquets avec la même version de python utilisée dans virtualenv. L'hypothèse serait que pip install résoudrait les choses de la même manière, mais ce n'est pas toujours le cas, même si je ne suis pas sûr à 100% de cela. Mais oui, pipenv lock n'est pas généré sur la base de virtualenv, il est généré sur la base de Pipfile . Il s'agit d'un fichier de verrouillage de résolution de dépendances, pas d'une broche d'état d'environnement.

Comme solution potentielle à ceci: quelque chose que pip lui-même prend actuellement en charge, mais pas pip-compile , est la notion de fichier de contraintes.

Un fichier de contraintes diffère d'un fichier d'exigences, en ce qu'il dit " Si ce composant est installé, il doit respecter cette contrainte de version". Cependant, si un package particulier du fichier de contraintes n'apparaît nulle part dans l'arborescence des dépendances, il n'est pas ajouté à l'ensemble de packages à installer.

C'est la fonctionnalité qui manque actuellement dans pipenv , car les entrées souhaitées pour la génération Pipfile.lock sont:

1. Le contenu Pipfile mis
2. L'ensemble complet des dépendances existantes de Pipfile.lock tant que fichier de contraintes, à l'exclusion des packages spécifiquement nommés dans la commande actuelle

La prise en charge des fichiers de contraintes au niveau du résolveur pip-tools serait alors suffisante pour pipenv pour prendre en charge un mode dans lequel les tentatives de mise à niveau implicite des dépendances échoueraient en tant que violation de contrainte, permettant à l'utilisateur de décider s'il voulait ou non ajouter ce package à l'ensemble en cours de mise à jour.

actuellement non pris en charge, merci pour les commentaires

@kennethreitz

Tu veux dire:

1. Ce comportement devrait être changé, mais ce n'est pas actuellement une priorité,
2. Ce comportement doit être ajouté comme quelque chose de facultatif, mais ce n'est pas actuellement une priorité, ou
3. Ce comportement ne doit pas être ajouté?

C'est un inconvénient suffisant étant donné l'incohérence avec la façon dont d'autres gestionnaires de paquets de verrouillage similaires fonctionnent, il serait bon de garder cela ouvert comme une sollicitation pour les PR.

Si à la place c'est (3), et que cela ne sera pas ajouté, alors je pense que nombre d'entre nous sur la question devront ajuster nos plans pour notre choix d'outils de gestion de paquets Python.

Je veux dire que ce n'est actuellement pas pris en charge, et j'apprécie les commentaires.

Je comprends que ce n'est pas pris en charge. Êtes-vous également en train de dire que vous n'accepteriez pas que les RP modifient ce comportement ou ne l'ajoutent pas en option?

Je n'ai aucune idée.

@ k4nar toujours intéressé à faire un PR pour ça? Plus précisément, quelque chose comme pipenv install --only <dep-to-update qui empêche la mise à jour de deps non liés. Puisque @kennethreitz ne semble pas intéressé à en discuter davantage, il me semble que c'est le seul moyen de savoir si cet ajout / changement de comportement pourrait être acceptable (et, par extension, si des gens comme @taion et moi pouvons continuer à utiliser pipenv).

Je suis intéressé mais je ne suis pas sûr de savoir comment serait la meilleure façon de mettre en œuvre cela. Il y a beaucoup de composants en action (pip, pip-tools, pipfile, pipenv…) et probablement beaucoup de solutions possibles.

Selon https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418, cela devrait être relativement simple. Cette logique de résolution de dep est en grande partie juste des outils de pip. J'avais l'intention de soumettre un PR, mais je ne peux pas justifier de dépenser le travail si nous ne sommes pas prêts à parler de la façon dont nous voulons que l'API ressemble avant de passer du temps à écrire du code.

Je cherche actuellement à adopter une approche alternative - comme Pipfile est un standard, les interactions avec celui-ci n'ont pas besoin de passer par pipenv, et j'aimerais contourner certaines des autres sémantiques étranges ici, comme l'effacement des virtualenv existants par https : //github.com/kennethreitz/pipenv/issues/997.

Désolé de commenter un problème clos, mais je tiens à souligner que, à ma connaissance, l'utilisation de pipenv dans mes projets nécessite actuellement un flux de travail comme celui-ci:

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

Je trouve vraiment ennuyeux de devoir communiquer cela aux membres de mon équipe. L'alternative semble être de tout épingler aux versions exactes dans Pipfile , mais cela va à l'encontre d'une grande partie de l'objectif d'utiliser pipenv en premier lieu.

IIUC, ce comportement est l'équivalent de apt exécutant un apt dist-upgrade implicite chaque fois que vous exécutez apt install foo .

Ceci est aggravé par le fait que pipenv install met Pipfile.lock , mais n'installe pas les mises à jour dans le virtualenv local. Si le développeur n'examine pas attentivement la différence de Pipfile.lock , il utilise toujours les anciennes versions localement, mais une fois qu'il partage le code, tous les autres environnements voient les mises à jour surprenantes. Les gens ont tendance à ignorer le diff de Pipfile.lock car il est considéré comme un fichier généré automatiquement.

Je suis fermement convaincu que "tout mettre à jour vers la dernière version autorisée par Pipfile " devrait être une opération explicitement demandée et distincte de "install foo".

devrait être corrigé dans master

Le comportement est toujours présent, je l'ai testé dans pipenv 11.8.3 , @kennethreitz.

@ marius92mc Le --selective-upgrade et --keep-outdated ajoutées dans les versions récentes: https://docs.pipenv.org/#cmdoption -pipenv-install-keep -dépassé

Cela permet aux personnes qui ont besoin ou veulent plus de contrôle sur exactement quand les mises à niveau se produisent d'accepter ce comportement, tandis que le comportement par défaut continue de respecter OWASP A9 et de pousser pour des mises à niveau avides à chaque occasion.

@ncoghlan Je pense qu'une chose qui est nécessaire (facile à demander, pas aussi facile à faire) est une FAQ sur _comment_ ces options se comportent (au moins c'est encore déroutant pour moi).

Par exemple: l'utilisation de --selective-upgrade et de --keep-outdated entraînera toujours la mise à jour des bibliothèques obsolètes dans Pipfile.lock , si elles ne sont pas directement liées au package "selected" à mettre à jour .

On dirait qu'il peut y avoir des bogues d'implémentation, alors.

Ils sont destinés à laisser le pipfile.lock tel quel, sauf pour la nouvelle modification.

Faites-moi savoir s'il est utile de fournir un test Pipfile + .lock.

Je pense que vous nous avez fourni suffisamment d'informations pour que nous puissions enquêter. Je vais essayer de le faire maintenant.

En fait, votre pipfile / lock serait génial s'il contient des résultats obsolètes.

@ncoghlan , merci d'avoir fourni les détails.
J'ai essayé à nouveau avec vos options mentionnées et le résultat semble être le même, il met également à jour les autres packages, en les modifiant dans le fichier Pipfile.lock .

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

Il y a des mises à jour sur ce problème, @kennethreitz?

Désolé pour la lenteur des réponses à ce sujet. Nous n'avons pas encore déterminé la cause fondamentale de la régression ici (je sais que j'ai personnellement géré une migration de centre de données ce week-end, j'ai donc été un peu lent), mais nous allons régler cela dans les prochains jours.

Les contributions sont les bienvenues comme toujours!

Je pense qu'il y a un cas d'utilisation manquant qui peut utiliser ce même changement: lorsque je développe une application, j'ai souvent besoin de mettre à niveau la version d'une seule dépendance. Les étapes que je souhaite suivre sont:

1. Mettez à jour la restriction de version pour la dépendance dans setup.py
2. Exécutez soit pipenv lock --selective-upgrade ; pipenv sync ou pipenv install --selective-upgrade "-e ."

@wichert Si Pipfile a été modifié de manière à augmenter la version minimale requise au-delà de ce qui est dans le fichier de verrouillage actuel, alors --keep-outdated devrait déjà couvrir ce dont vous avez besoin. --selective-upgrade est pour le cas où Pipfile n'a pas changé, mais vous voulez quand même mettre à jour vers une nouvelle version épinglée.

@ncoghlan Pipfile n'a pas changé dans ce scénario, seulement setup.py en changeant la version minimale requise pour une dépendance, généralement à quelque chose de plus récent et actuellement dans Pipfile.lock .

@wichert pipenv ne capture pas automatiquement les modifications apportées à votre setup.py car ce n'est pas setuptools. Vous devez exécuter pipenv lock si vous voulez que cela se produise.

Quel est le statut actuel de cela? Le 25 mars, quelqu'un a dit qu'il pensait que les problèmes d'implémentation seraient résolus "dans les prochains jours", et d'autres rapports de bogues ont été fermés en raison du suivi ici; mais à partir de 2018.7.1, je vois toujours le bogue signalé par Simon Percivall (les dépendances indirectes sont toujours mises à jour) et ce bogue n'a pas été discuté depuis le rapport original. Le problème est-il toujours suivi?

(Je vis actuellement dans une ville de deuxième niveau au Sénégal, donc mon Internet est terrible et ce serait un changement de jeu de ne pas faire sauter mon plafond de données sur la mise à jour des dépendances indirectes si possible: P)

PS: Merci d'avoir fait Pipenv, c'est génial <3

Oui bien sûr. Nous réécrivons le résolveur pour prendre en charge cela maintenant. Reste à savoir s'il atterrira dans cette version ou dans la prochaine version

Je ne suis pas si confiant avec mes compétences en codage pour estimer quand le résolveur atterrirait: p Sérieusement, il s'agit d'un projet entièrement bénévole, et nous n'avons pas de mécanisme de délai comme vous le feriez dans des contextes commerciaux (nous n'avons même pas un patron ou un chef de projet ou tout ce que vous avez dans votre entreprise qui décide quand une chose doit être faite). Si vous voulez qu'une chose soit faite dans un délai que vous désirez, vous devez le faire vous-même, ou au moins fournir une réelle motivation aux autres pour le faire.

@uranusjr FWIW, je n'ai vu aucune demande d'opportunité dans le commentaire de @benkuhn ci-dessus - juste une question sur où en sont les choses; c'est-à-dire quel travail a été fait, afin que les observateurs extérieurs puissent faire leurs propres estimations / décisions.

Je comprends que pipenv est un projet bénévole et que les non-contributeurs ne peuvent demander qu'une chose soit faite avant une date sans s'inscrire pour y arriver. Je me demande s'il y a place pour plus de transparence dans le processus de développement du projet, ou si je ne cherche tout simplement pas aux bons endroits. Habituellement, la réponse est "si le problème n'a pas été mis à jour, il n'y a pas eu de mouvement" ou "regardez cette demande de tirage WIP", mais ce problème en particulier semble avoir déclenché un effort beaucoup plus important, les points peuvent donc être difficiles. pour se connecter pour ceux qui ne sont pas directement impliqués.

Comme toujours, merci à vous et à tous ceux qui consacrent leur temps précieux à l'amélioration de pipenv. 👏

Bien sûr, celui-ci n'a pas d'activité ou de travail en cours de PR car c'est beaucoup plus compliqué que ça. Nous parlons principalement en interne de la manière dont nous voulons même structurer cela par rapport au projet plus large, et en travaillant de manière itérative pour établir une approche qui pourrait même commencer à fonctionner correctement. Une fois que nous pouvons régler cela, nous pouvons construire une logique de résolution.

En attendant, la pile de résolveurs dans pipenv est très compliquée et je ne serais pas à l'aise de demander aux gens d'investir trop d'efforts pour essayer de le démêler à cette fin. Même le cas d'utilisation le plus simple ici nécessitera un refactor important. Nous serions heureux de revoir / discuter de tout refactor proposé si quelqu'un souhaite aider à résoudre ce problème, mais les deux choses sont étroitement liées.

Si quelqu'un a une expertise dans la résolution de dépendances et la résolution de sat, nous serions certainement intéressés par des contributions, mais il n'y a tout simplement pas encore une seule idée concrète. Nous avons traversé plusieurs itérations que nous n'avions jamais prévu de poursuivre comme plus qu'une preuve de concept. Tout le code ne devient pas un PR, et toutes les décisions d'organisation du code ne se produisent pas sur le suivi des problèmes. Parfois, nous discutons de manière synchrone et proposons et supprimons des idées en temps réel.

Quelque chose que j'allais _voir_ suggérer comme flux de travail alternatif qui pourrait résoudre ce problème est de faciliter l'épinglage à une version spécifique du _Pipfile_ lors de l'installation.

Je pense que c'est un peu surprenant mais pas complètement déraisonnable que pipenv interprète foo = "*" comme signifiant "je dois juste m'assurer que _une_ version de foo est installée, l'utilisateur ne se soucie pas de laquelle". À cette fin, avoir quelque chose comme pipenv install --pin foo qui se traduit par foo = "==1.2.3" au lieu de foo = "*" dans le Pipfile (où 1.2.3 est la dernière version actuelle de foo) semble Aidez-moi.

Le problème avec cela est que le comportement de nombreux packages peut beaucoup changer en fonction de leurs dépendances (par exemple, la même version de pylint peut faire des choses totalement différentes en fonction de la version d'astroid qu'il utilise), et les packages ne le font pas. épingler leurs propres deps exactement. Donc, je ne pense pas que cela mène vraiment quelqu'un très loin. : /

(Je viens de réaliser que j'ai commenté le mauvais problème. Désolé pour le gâchis, veuillez m'ignorer) 😞

Un cas d'utilisation réel avec lequel je me débat depuis quelques heures maintenant: je souhaite mesurer la couverture de test dans un projet Django 2.0. Même pipenv install --keep-outdated --selective-upgrade --dev coverage insiste pour mettre à jour le paquet Django non-dev vers la version 2.1, que je ne peux absolument pas encore utiliser à cause d'une panne ailleurs. Il doit vraiment La possibilité de casse dans la dernière version existera toujours.

Je vais essayer la solution de contournement de @rfleschenberg , mais je ne sais pas si avoir une propriété _meta hash vraisemblablement incorrecte cassera quelque chose.

@ l0b0 Si votre application ne peut vraiment pas gérer une version particulière de Django, je pense qu'il est logique d'indiquer cette restriction dans votre Pipfile?

@AlecBenzer Cela ressemble à quelque chose pour setup.py pour moi.

@wichert Cela peut aussi avoir un sens (je ne suis en fait pas tout à fait clair sur les circonstances dans lesquelles vous voudriez avoir à la fois un setup.py et un Pipfile), mais si vous avez une ligne dans votre Pipfile qui dit:

Django = "*"

vous dites à pipenv que vous voulez qu'il installe _toute_ version de Django. Si vous voulez vraiment qu'il installe 2.0 ou une version antérieure, dites-lui plutôt que:

Django = "<=2.0.0"

Alors que dans ce cas particulier, pipenv met à jour Django sans raison réelle, il se peut que quelque part sur la ligne vous essayez d'installer un paquet qui nécessite Django> 2.0.0, auquel point pipenv l'installera avec plaisir si vous ne l'avez pas dit il que vous avez besoin de <= 2.0.0.

Si vous voulez vraiment qu'il installe la version 2.0 ou une version antérieure, dites-lui plutôt

@AlecBenzer à la réflexion, il me vient maintenant à l' ^major.minor.0 dans package.json, ce qui empêche les mises à jour majeures inattendues, même lorsqu'une mise à niveau vers la dernière est explicitement demandée. Je me demande si Pipenv devrait faire de même - mais ce serait une question distincte.

Bien sûr, leur fichier de verrouillage empêche également les mises à niveau accidentelles de versions, même mineures et de correctifs, ce qui est demandé ici.

Je pense que cela a été discuté ci-dessus et ailleurs, mais il y a une tension / un compromis dans l'espace de conception entre npm / yarn et pipenv. Tout gestionnaire de packages a ostensiblement ces objectifs, avec une priorité relative:

• Facilitez l'installation et la mise à niveau des packages
• Rendre difficile la rupture accidentelle de votre application avec une mise à niveau de dépendance errante

Le problème avec l'épinglage d'une version exacte dans le Pipfile est qu'il est alors plus difficile de mettre à niveau les paquets; c'est pourquoi pip-tools existe (bien que ce soit pour requirements.txt).

L'indicateur --keep-outdated ne semble pas fonctionner comme prévu, comme cela a été indiqué lors de la réouverture du problème. Que ce comportement doive ou non être la valeur par défaut et comment il s'aligne avec d'autres gestionnaires de packages n'est pas vraiment le problème central ici. Commençons par régler le problème.

@brettdh

à la réflexion, il me vient maintenant à l'esprit que c'est ce que fait npm / yarn par défaut lorsque vous installez un paquet; ils trouvent la dernière version major.minor et spécifient ^ major.minor.0 dans package.json, ce qui empêche les mises à jour majeures inattendues, même lorsqu'une mise à niveau vers la dernière est explicitement demandée. Je me demande si Pipenv devrait faire de même - mais ce serait une question distincte.

Oui, c'est dans le sens de ce que j'essayais de suggérer dans https://github.com/pypa/pipenv/issues/966#issuecomment -408420493

Vraiment excité d'entendre que cela est en cours d'élaboration!

En attendant, quelqu'un a-t-il une solution de contournement suggérée qui est moins laborieuse et sujette aux erreurs que d'exécuter pipenv lock et de revenir manuellement aux modifications de fichier de verrouillage résultantes que je ne veux pas appliquer?

@benkuhn Pas à ce que je sache - je fais la même danse de verrouillage et de retour tout le temps.

Ah ok, vous pouvez au moins parfois éviter le retour manuel:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. Supprimez le commit FIXME: revert

Malheureusement, il est toujours possible de créer un Pipfile.lock incohérent si votre Pipfile.lock commence par contenir une version d'un paquet trop ancien pour satisfaire les exigences de packagename , mais peut-être que pipenv se plaindra à ce sujet si cela se produit?

--keep-outdated semble ne garder systématiquement obsolètes que les dépendances explicites spécifiées (non épinglées) dans Pipfile, tandis que toutes les dépendances implicites sont mises à jour.

Ai-je raison de dire qu'il n'est pas possible de mettre à jour / installer une seule dépendance en utilisant pipenv==2018.7.1 sans mettre à jour d'autres dépendances? J'ai essayé différentes combinaisons de --selective-upgrade et --keep-outdated sans succès.

Modifier manuellement Pipfile.lock n'est pas amusant ...

Identique à @ max-arnold, c'est mon premier jour à utiliser l'outil dans un projet existant, et je dois dire que je suis vraiment déçu , avant de commencer à l'utiliser, j'ai vérifié le site doc et la démo vidéo, ça avait l'air impressionnant pour moi, et maintenant ceci: dans un vrai projet, travailler avec pip ou pipenv est presque le même, je ne vois pas l'intérêt, comme beaucoup d'autres l'ont dit dans le fil, si j'ai un fichier de verrouillage, pourquoi vous mettez à jour mes autres dépendances s'il n'est pas nécessaire de les mettre à jour.

Bien sûr, ### si la mise à jour est obligatoire, vous pouvez mettre à jour toutes les dépendances nécessaires, mais seulement celles-ci, pas toutes celles qui sont obsolètes.

De plus, les options --selective-upgrade et --keep-outdated ne sont pas claires pour ce qui est utile, il y a un autre problème qui le souligne ici # 1554, et personne n'est en mesure de répondre à ce que ces options font, incroyable.

Mais ma principale déception est la raison pour laquelle ce paquet a été recommandé par la documentation officielle de Python elle-même, ces recommandations devraient être plus prudentes, je sais que cela peut être un excellent projet dans la fonctionnalité, avoir beaucoup de potentiel, mais des choses simples comme celle-ci (nous ne parlent pas d'un bug ou d'une fonctionnalité mineure), rendez ce projet non éligible pour les environnements de production, mais du coup parce qu'il a été recommandé par la documentation Python, tout le monde essaie de l'utiliser, au lieu de chercher d'autres outils qui fonctionnent peut-être mieux, ou simplement s'en tenir à pip , cela ne résout pas également ces problèmes, mais au moins c'est très minimaliste et il est principalement inclus dans n'importe quel environnement (n'ajoute pas de dépendances supplémentaires).

@mrsarm Merci pour votre avis. Désolé, les choses ne fonctionnent pas pour vous. Cependant, je ne comprends pas d'où vient la déception. Personne n'impose Pipenv à personne; si cela ne fonctionne pas pour vous, ne l'utilisez pas. C'est ainsi que fonctionnent les recommandations.

Votre diatribe n'a rien de particulièrement lié à ce problème. Je comprends qu'il faut un peu de maîtrise de soi pour ne pas jeter les ordures sur les gens quand les choses ne vont pas comme vous le souhaitez, mais veuillez faire preuve de respect et ne pas le faire.

@uranusjr ce n'est pas une poubelle, c'est une opinion, et parfois ce n'est pas une option, comme mon cas, où quelqu'un a choisi pipenv pour créer un projet où j'ai commencé à travailler maintenant, et je dois gérer cela.

Mais les choses empirent en ce moment, et ce que je vais dire, ce n'est pas une opinion, c'est un fait.

Après avoir essayé d'ajouter une dépendance que j'ai juste écartée pour éviter de traiter ce problème (car c'est une dépendance de développement, j'ai donc créé un deuxième environnement avec pip et l'ancienne approche requirements-dev.txt , juste avec cet outil), j'avais besoin d'ajouter une autre dépendance.

La nouvelle dépendance est PyYAML, disons la dernière version. Si vous l'installez dans un nouvel environnement avec pip , vous verrez que la bibliothèque n'ajoute aucune dépendance, donc seul PyYAML est installé, c'est aussi simple dans ces cas avec Pip. Mais en ajoutant la dépendance avec Pipenv (car un projet que je n'ai pas créé est géré avec Pipenv), le même problème s'est produit, bien que PyYAML n'ait aucune dépendance et qu'il n'ait pas été précédemment installé dans le projet (une version plus ancienne), pipenv met

Donc la conclusion (et encore une fois un avis, pas un fait comme pipenv a cassé toutes mes dépendances) c'est que Pipenv au lieu de m'aider à gérer la gestion des dépendances, ça le transforme en enfer.

J'ai suivi ce fil pendant des mois et je pense que tout projet réel finira par tomber sur ce problème, car le comportement est inattendu, contre-intuitif et oui: dangereux.

Il y a environ un mois, j'ai essayé une alternative plus complète à pipenv , poetry ; il a résolu les problèmes que je devais résoudre:
1) gérer un ensemble de dépendances (setup.py, setup.cfg, pip et pipfile -> pyproject.toml)
2) orienté vers l'avenir, rétrocompatible (encore une fois
3) assez sans opinion ( non, je ne demande vraiment pas d'installer redis )
4) et la solution au problème classique de Pipenv: "De plus, vous devez lui dire explicitement [pipenv] de ne pas mettre à jour les paquets verrouillés lorsque vous en installez de nouveaux. Cela devrait être la valeur par défaut." [[1] (https://github.com/sdispater/poetry#what-about-pipenv)] [[2] (https://github.com/pypa/pipenv/issues/966#issuecomment-339117289)]

J'ai pesé en partageant ces réflexions sur le problème pipenv , mais comme @uranusjr l'a dit, "personne ne force Pipenv sur personne", et je ne force pas Poetry. J'aime ça, ça marche bien et ça résout mes problèmes, mais je partage juste une solution alternative plus complète au problème que j'avais. Prenez tout cela pour mes 2 ¢.

• à titre d'avertissement, je ne suis pas membre de l'équipe Poetry ou affilié à eux.

ps Je pense que la préoccupation de Pipenv en tant que solution "officielle" est due à ses intégrations de @uranusjr , pourriez voir comme une simple recommandation - l'industrie dans son ensemble la considère comme une "approche bénie en cours vers l'avant". Franchement, cette recommandation fait plus autorité dans la communauté que certaines PPE qui existent depuis plus d'un an.

Personne ne vous oblige à participer à notre outil de suivi des problèmes; si vous n'avez pas de commentaire productif, veuillez trouver un forum qui n'est pas pour le tri des problèmes.

Pour les utilisateurs qui souhaitent essayer le résolveur alternatif @uranusjr et moi-même l'implémentons depuis plusieurs semaines maintenant, veuillez essayer https://github.com/sarugaku/passa qui générera des fichiers de verrouillage compatibles. La poésie fait beaucoup de choses différentes, mais elle a aussi des limites et des problèmes en elle-même, et nous avons un désaccord de philosophie de conception sur la portée.

C'est un projet que nous gérons pendant notre temps libre; si vous voulez voir quelque chose de fixe ou si vous avez une meilleure approche, nous sommes heureux d'accepter les contributions. Si vous êtes ici pour nous dire simplement que nous avons gâché votre journée et votre projet, je ne vous demanderai qu'une seule fois de vous voir.

Nous n'avons pas oublié ou ignoré ce problème, nous avons une implémentation complète d'un correctif dans le résolveur lié ci-dessus. Ayez de la patience, soyez courtois ou trouvez un autre endroit pour parler. Pour ceux qui ont attendu patiemment une solution, veuillez essayer le résolveur mentionné ci-dessus - nous sommes impatients de voir s'il répond à vos besoins. Il met en œuvre un retour en arrière et une résolution appropriés et ne devrait pas gérer cette stratégie de mise à niveau

À court terme, je pense que nous pouvons obtenir un pansement pour cela dans pipenv si nous ne finissons pas par couper en premier.

@dfee Je ne suis pas vraiment sûr que le flou entre les applications et les bibliothèques soit la bonne réponse à la gestion des dépendances, donc je ne vois pas l'approche de la poésie comme un avantage. Je n'ai pas été impliqué dans votre problème avec le moteur de recommandation, mais nous l'avons éliminé il y a quelque temps ...

@techalchemy

Je ne suis pas vraiment sûr que le flou entre les applications et les bibliothèques soit la bonne réponse à la gestion des dépendances, donc je ne vois pas l'approche de la poésie comme un avantage.

Pourquoi alors? Je n'ai jamais compris cette idée de gérer différemment les dépendances d'une bibliothèque et d'une application. La seule différence entre les deux est le fichier de verrouillage qui est nécessaire pour qu'une application assure un environnement reproductible. A part ça, c'est la même chose. C'est la norme dans la plupart des autres langages et Python semble l'exception ici pour une raison quelconque et c'est mauvais du point de vue de l'expérience utilisateur car cela rend les choses plus complexes qu'elles ne devraient l'être.

il a également des limites et des problèmes lui-même

Lesquels? Je suis vraiment curieux de connaître les problèmes ou les limites que vous avez rencontrés lors de l'utilisation de Poetry.

Mes excuses pour haricot si grossier. En lisant mes commentaires, je me rends compte que malgré les informations que j'ai fournies et que certaines de mes options sont toujours valables (à mon humble avis), cela n'a pas été approprié comme j'ai écrit ce que je voulais dire.

Je comprends que le suivi des problèmes est surtout un endroit où discuter des bogues et des améliorations, et discuter s'il s'agit d'un bogue ou d'une erreur de conception n'est pas clair dans le fil de discussion, mais encore une fois, mes excuses.

Je pense qu'il y a deux sujets forts ici:

• Pipenv devrait-il mettre à jour toutes vos dépendances obsolètes où vous essayez simplement d'installer une nouvelle dépendance: celles qui ne sont pas nécessaires parce que le nouveau package / version que nous essayons d'installer peut fonctionner avec les dépendances existantes, et même celles qui ne le sont pas Les dépendances du nouveau paquet que nous essayons d'installer? C'est peut-être hors de portée de ce ticket, mais c'est un sujet vraiment important à discuter.
• Est-ce que l'un de ces paramètres --keep-outdated --selective-upgrade nous permet d'éviter ces comportements? Ce que font ces options n'est pas clair, il y a un manque de documentation à leur sujet, et même dans le problème connexe (# 1554) personne ne répond à cela.

Au cas où il y aurait un bug dans l'un de ces paramètres --keep-outdated --selective-upgrade , je pense toujours que ne pas définir le paramètre résout la mise à jour inutile des dépendances par défaut, c'est une très mauvaise idée.

Pour comparer avec un scénario similaire, imaginez que vous exécutez apt-get install vim pour simplement installer l'outil vim dans votre système (et les dépendances ou mises à jour de vim nécessaires le cas échéant), mais imaginez aussi que dans cette situation apt met à jour toutes les autres dépendances de votre système: python, le système QT, le noyau Linux ... et ainsi de suite. Ce n'est pas qu'apt ne devrait pas nous permettre de mettre à jour d'autres dépendances, mais il existe une commande claire pour le faire: apt-get upgrade , tandis que apt-get install PACKAGE installe / met à jour PACKAGE et ses dépendances.

@sdispater la distinction est au cœur de chaque désaccord que nous ayons jamais eu et c'est incroyablement subtil, mais je vous indiquerais https://caremad.io/posts/2013/07/setup-vs-requirement/ ou un bon article pour le cas d'utilisation d'élixir: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml n'est pas vraiment pris en charge pour les métadonnées de définition de bibliothèque - et pas du tout par les versions de pip qui n'implémentent pas les peps 517 et 518 (qui ont toujours des détails d'implémentation élaborés) en tant qu'autorité fichier de déclaration de bibliothèque. setup.cfg existe à cette fin (le successeur réel de setup.py ) et à mon humble avis, les deux devraient vraiment être pris en charge. Une bibliothèque est publiée et destinée à être consommée avec des dépendances abstraites afin qu'elles puissent jouer bien dans le bac à sable avec d'autres; les applications sont généralement de grandes bêtes complexes avec parfois des centaines de dépendances directes. L'une de nos principales divergences est que lorsque nous concevons et construisons notre outillage, nous en tenons également compte

@mrsarm Pour votre première question, le comportement de la mise à jour était intentionnel (et a été largement discuté à l'époque, / cc @ncoghlan et lié aux problèmes de sécurité OWASP). Sur le deuxième point, le comportement n'est actuellement pas correctement implémenté, c'est pourquoi le problème est toujours ouvert, ce qui nous a conduit à réécrire le résolveur de support derrière pipenv, que j'ai mentionné plus haut. Il n'a tout simplement pas soutenu ce comportement. --selective-upgrade est censé mettre à niveau de manière sélective uniquement les éléments qui sont des dépendances du nouveau paquet, tandis que --keep-outdated retiendrait tout ce qui satisfait les dépendances requises par un nouveau paquet. Légèrement différent, mais je suis assez sûr qu'aucun des deux ne fonctionne correctement pour le moment.

pyproject.toml n'est pas vraiment pris en charge pour les métadonnées de définition de bibliothèque - et pas du tout par les versions de pip qui n'implémentent pas peps 517 et 518 (qui ont toujours les détails d'implémentation élaborés) en tant que fichier de déclaration de bibliothèque faisant autorité . setup.cfg existe à cette fin (le successeur réel de setup.py) et à mon humble avis, les deux devraient vraiment être pris en charge.

Eh bien, c'est certainement hors sujet mais c'est une discussion importante, donc je ne peux pas m'en empêcher.

Il n'y a actuellement aucune norme autour de setup.cfg autre que les conventions établies par distutils et setuptools. pyproject.toml est absolument pour les métadonnées de bibliothèque en tant que successeur de setup.py ou la communauté aurait placé des exigences de construction dans setup.cfg place.

pyproject.toml décrit comment construire un projet (PEP 518), et une partie de la construction décrit les métadonnées. Je ne dis PAS que pyproject.toml besoin d'un emplacement standard pour ces métadonnées, mais PEP 518 utilise ce fichier pour installer un outil de construction et à partir de là, il est très raisonnable de s'attendre à ce que l'outil de construction utilise une configuration déclarative ailleurs dans le fichier pour déterminer comment créer le projet.

Quoi qu'il en soit, pour revenir à pipenv vs poetry - il semble y avoir une idée flottante selon laquelle les applications n'ont pas besoin de certaines fonctionnalités que les bibliothèques obtiennent, comme les points d'entrée, et c'est tout simplement incorrect. Il devrait être simple pour une application d'être un package python.

La seule vraie différence entre une application et une bibliothèque dans mon expérience avec python et avec d'autres écosystèmes est de savoir si vous utilisez un fichier de verrouillage ou non. Bien sûr, il y a un troisième cas où vous voulez vraiment juste un requirements.txt ou Pipfile et pas de code réel et cela semble être tout ce sur quoi pipenv s'est concentré jusqu'à présent ( pipenv install -e . tombe dans cette catégorie car pipenv a toujours peur d'essayer de prendre en charge les métadonnées du package). Malheureusement, bien que la conception de pipenv soit plus propre avec cette approche, elle est également beaucoup moins utile pour la plupart des applications car PEP 518 a décidé de déterminer comment installer des projets en mode modifiable afin de continuer à utiliser pipenv, nous serons bloqués sur setuptools pendant plus longtemps car vous ne pouvez pas utiliser pyproject.toml pour quitter setuptools et continuer à utiliser pipenv install -e . .

Il n'y a actuellement aucun standard autour de setup.cfg autre que les conventions établies par distutils et setuptools. pyproject.toml est absolument pour les métadonnées de la bibliothèque car le successeur de setup.py ou la communauté aurait placé les exigences de construction dans setup.cfg à la place.

Distutils fait partie de la bibliothèque standard et setuptools est maintenant installé avec pip, donc dire qu'il n'y a pas de standard est un peu ridicule. Sans oublier qu'il utilise la norme décrite dans pep 345 pour les métadonnées, entre autres, et peut également être utilisé pour spécifier les exigences de construction.

la communauté aurait plutôt placé les exigences de construction dans setup.cfg.

Voulez-vous dire les auteurs pep? Vous pouvez leur demander pourquoi ils ont pris leur décision, ils décrivent tout dans le pep.

pyproject.toml décrit comment construire un projet (PEP 518), et une partie de la construction décrit les métadonnées. Je ne dis PAS que pyproject.toml a besoin d'un emplacement standard pour ces métadonnées, mais PEP 518 utilise ce fichier pour installer un outil de construction et à partir de là, il est très raisonnable de s'attendre à ce que l'outil de construction utilise une configuration déclarative ailleurs dans le fichier pour déterminer comment construire le projet.

Ceci est apparu sur la liste de diffusion récemment - rien nulle part n'a déclaré une norme autour de pyproject.toml autre que celle qui sera utilisée pour déclarer la configuration système requise. Tout le reste est une hypothèse; vous pouvez appeler cela des "métadonnées de définition de bibliothèque", mais ce n'est pas le cas. Essayez de définir uniquement un système de construction sans informations supplémentaires sur votre projet (c'est-à-dire sans métadonnées compatibles pep-345) et téléchargez-le sur pypi et faites-moi savoir comment cela se passe.

Quoi qu'il en soit, pour revenir à pipenv vs poetry - il semble y avoir une idée flottante selon laquelle les applications n'ont pas besoin de certaines fonctionnalités que les bibliothèques obtiennent, comme les points d'entrée, et c'est tout simplement incorrect. Il devrait être simple pour une application d'être un package python.

Qui dit que les applications ne nécessitent pas de points d'entrée? Pipenv a une structure entière pour gérer cela.

afin de continuer à utiliser pipenv, nous serons bloqués sur setuptools pendant un certain temps car vous ne pouvez pas utiliser pyproject.toml pour quitter setuptools et continuer à utiliser pipenv install -e.

Ne pas suivre ici ... nous n'allons pas laisser pip vendu à la version 10 pour toujours, j'ai littéralement décrit notre nouveau résolveur, et le programme d'installation actuel revient directement à pip directement ... comment cela empêche-t-il les gens d'utiliser editable installe?

Cela est apparu récemment sur la liste de diffusion - rien nulle part n'a déclaré de norme autour de pyproject.toml

C'est correct, ce n'est pas un "standard", mais dans ce même fil, reconnaissez qu'en l'appelant pyproject.toml ils ont probablement demandé aux gens d'utiliser ce fichier pour d'autres paramètres / config liés au projet.

Donc, par la même logique que vous avez invoquée ici:

Distutils fait partie de la bibliothèque standard et setuptools est maintenant installé avec pip, donc dire qu'il n'y a pas de standard est un peu ridicule.

pyproject.toml est un standard, et la communauté l'a adopté comme emplacement standard pour placer les informations relatives au système de construction et à d'autres parties d'un projet Python.

Ne pas suivre ici ... nous n'allons pas laisser pip vendu à la version 10 pour toujours, j'ai littéralement décrit notre nouveau résolveur, et le programme d'installation actuel revient directement à pip directement ... comment cela empêche-t-il les gens d'utiliser editable installe?

PEP 517 punté sur des installations modifiables ... ce qui signifie qu'il n'y a pas de moyen standard d'installer un projet en mode modifiable si vous n'utilisez pas d'outils de configuration (qui a un concept connu sous le nom de mode de développement qui installe le projet en mode modifiable).

Distutils fait partie de la bibliothèque standard et setuptools est maintenant installé avec pip, donc dire qu'il n'y a pas de standard est un peu ridicule. Sans oublier qu'il utilise la norme décrite dans pep 345 pour les métadonnées, entre autres, et peut également être utilisé pour spécifier les exigences de construction.

Oui, le système de construction devrait générer le fichier PKG-INFO décrit dans PEP 345. Il s'agit d'un format de transfert qui va dans une sdist ou une roue et est généré à partir d'un setup.py/setup.cfg, ce n'est pas un remplacement car tel pour les métadonnées destinées à l'utilisateur. L'utilisation de pyproject.toml PEP 518 concerne la prise en charge d'alternatives à distutils / setuptools en tant que système de construction, personne n'essaie de remplacer les formats sdist / wheel pour le moment. Ces systèmes de construction de remplacement ont besoin d'un endroit pour mettre leurs métadonnées et, heureusement, PEP 517 a réservé l'espace tool. noms flit et poetry ont adopté cet espace de noms pour les «métadonnées de définition de bibliothèque».

Essayez de définir uniquement un système de construction sans informations supplémentaires sur votre projet (c'est-à-dire sans métadonnées compatibles pep-345) et téléchargez-le sur pypi et faites-moi savoir comment cela se passe.

Comme c'est constructif.

Qui dit que les applications ne nécessitent pas de points d'entrée? Pipenv a une structure entière pour gérer cela.

Où est cette construction? Je ne trouve même pas le mot «entrée» sur aucune page de la documentation de pipenv à https://pipenv.readthedocs.io/en/latest/ donc «une construction entière» semble assez farfelue? Si vous voulez dire des installations modifiables, nous avons atteint le point que je voulais dire ci-dessus - avec pipenv décidant de se coupler à pipenv install -e . comme seul moyen de se connecter et de développer une application sous forme de package, dans un avenir prévisible, le support de pipenv ici est couplé à setuptools. Je pense que toute la controverse se résume vraiment à ce point et les gens (certainement moi) sont frustrés que nous puissions maintenant définir des bibliothèques qui n'utilisent pas setuptools mais ne peuvent pas se développer dessus avec pipenv. Pour être parfaitement clair, ce n'est pas strictement la faute de pipenv (PEP 518 a décidé de lancer des installations modifiables), mais son refus de reconnaître le problème a été frustrant dans le discours car la poésie fournit une alternative qui gère ce problème d'une manière conforme. au format pyproject.toml . Pipenv n'arrête pas de dire que la poésie prend de mauvaises décisions mais n'essaie pas réellement de montrer la voie à suivre.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

Veuillez lire la documentation.

@bertjwregeer :

pyproject.toml est un standard, et la communauté l'a adopté comme emplacement standard pour placer les informations liées au système de construction et à d'autres parties d'un projet Python.

Génial, et nous sommes heureux d'accueillir les sdists et les roues construits à l'aide de ce système et jusqu'à ce qu'il y ait une norme pour les installations modifiables, nous continuerons à utiliser pip pour créer des sdists et des roues et gérer la résolution des dépendances de cette façon. Veuillez lire mes réponses dans leur intégralité. Les auteurs et mainteneurs de pip, des peps en question, et moi-même et @uranusjr connaissent assez bien les différences entre les installations modifiables et les implications de leur construction sous les contraintes de pep 517 et 518. Jusqu'à présent, tout ce que je vois est-ce que les peps en question n'ont pas spécifiquement abordé comment les construire parce qu'ils laissent à l'outillage, ce qui pour une raison quelconque, tout le monde pense que pipenv ne pourra jamais utiliser autre chose que setuptools?

J'ai déjà dit que ce n'était pas correct. Si vous êtes réellement intéressé par la mise en œuvre et que vous avez une conversation productive, je suis heureux de l'avoir. Si vous êtes simplement ici pour dire que nous ne savons pas ce que nous faisons, mais que vous n'êtes pas intéressé à savoir ce que nous faisons, c'est votre seul avertissement. Nous sommes des volontaires avec un temps limité et je pratique une politique de tolérance 0 pour les engagements toxiques. Je ne prétends pas que mon travail est parfait et je ne prétends pas que pipenv est parfait. Je serai heureux de consacrer mon temps et mes efforts à ce genre de discussions; en échange, je demande qu'ils soient respectés, qu'ils s'en tiennent aux faits et que ceux qui participent soient également disposés à apprendre, à m'écouter et à m'écouter. Si vous êtes ici juste pour soapbox, vous devrez trouver une autre plate-forme; il s'agit d'un outil de suivi des problèmes. Je le modérerai si nécessaire.

Cette discussion est complètement hors sujet . Si quelqu'un a quelque chose de constructif à dire sur le problème en question, n'hésitez pas à poursuivre cette discussion. Si quelqu'un a des problèmes ou des questions sur nos implémentations de système de build, veuillez ouvrir un nouveau problème. Si vous rencontrez des problèmes avec notre documentation, nous acceptons de nombreuses demandes d'extraction autour de la documentation et nous sommes conscients qu'elle a besoin de travail. Veuillez reporter toute cette discussion à de nouvelles questions pour ces sujets. Et s'il vous plaît noter: les mêmes règles s'appliqueront toujours - ce n'est pas une boîte à savon, c'est un suivi des problèmes.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
Veuillez lire la documentation.

Les points d'entrée sont un concept plus général que de simples scripts de console et ce lien est complètement erroné pour répondre à ces préoccupations. <soapbox> Interdire - vous n'êtes pas le seul mainteneur de grands projets open source ici et aucun de mes commentaires n'a été une attaque personnelle contre vous ou le projet. Les gens qui commentent ici le font parce qu'ils veulent utiliser pipenv et apprécient beaucoup ce qu'il fait. Mon commentaire n'était pas le premier article hors sujet sur ce fil, mais il est le seul marqué. Vos commentaires sournois indiquant que vous pensez que je ne sais pas de quoi je parle sont embarrassants et toxiques.

Dans le projet que nous maintenons, nous pouvons faire de la boîte à savon. Et oui, pip prendra en charge tous les systèmes de construction conformes que vous semblez bien comprendre tous les deux produira des métadonnées consommables, et comme pipenv utilise pip comme outil de support pour piloter son processus d'installation, comme je l'ai décrit, oui, pipenv prendra en charge tous les outillage. Je l'ai déjà dit.

Alors oui, veuillez emporter votre toxicité ailleurs. Votre attitude n'est pas la bienvenue ici. Dernier avertissement. Les tentatives persistantes d'incitation au conflit ne seront pas tolérées.