Readthedocs.org: Fichier de support

Merci @Stibbons. Les contributions sont toujours les bienvenues, bien sûr, si vous souhaitez soumettre un PR pour cela.

J'ai commencé à jouer avec la prise en charge de pipenv, il semble que cela puisse remplacer les appels à l'installation de pip. Nous voudrons probablement offrir l'option via notre fichier readthedocs.yml, cela prendra donc :

• [ ] Appel conditionnel à pipenv dans doc_builder/python_environments.py
• [ ] prise en charge de readthedocs.yml dans notre référentiel readthedocs-build
• Prise en charge de [ ] readthedocs.yml dans ce référentiel

oui, c'est un remplacement direct de pip (en fait, un wrapper), vous faites pipenv install thispackage et il installe le package dans virtualenv (en utilisant pew) et modifie Pipfile en conséquence. Pour ReadTheDocs, je vous suggère de faire pipenv install --dev et de vous assurer que la lib est installée dans l'environnement. J'utilise habituellement -e . pour injecter ma lib en développement dans le virtualenv, mais je ne suis pas sûr que tout le monde le fasse

Vous devriez réellement faire pipenv install --dev --ignore-pipfile . Sans --ignore-pipfile , pipenv cherchera simplement à mettre à niveau les packages dans Pipfile et ne fera pas vraiment de build déterministe. Voir https://github.com/kennethreitz/pipenv/issues/954#issuecomment -338777638.

En effet

J'utilise déjà pipenv pour d'autres projets, alors ayez une certaine familiarité. Je pense que dans notre cas, nous voulons également que --system utilise nos virtualenvs existants. Nous avons un stockage spécial pour cela, afin que les venvs persistent à travers les versions.

@tuukkamustonen cela me

Je suppose que le plus correct est de vérifier pipfile.lock, si c'est le cas, --ignore-pipfile , sinon non ?

Certaines de ces options seront probablement ajoutées/autorisées via notre readthedocs.yml, --dev fait probablement partie.

Dans le cas d'un requirements.txt , nous devrions pouvoir utiliser simplement pipenv install au lieu de pip install

Les deux côtés sont ok. Lorsque vous figez le fichier requirements.txt (par exemple en utilisant pip-tools), il agit comme lorsque vous utilisez le fichier de verrouillage.
Lorsque vous décrivez uniquement la version par plage ou sans version, cela agit comme Pipfile.
Le fichier de verrouillage est spécifique à la machine, il n'a pas les marqueurs (ex « python_version < 3 »), mais les deux devraient fonctionner.
J'utiliserais 'pipenv install —dev —system', c'est comme 'pip install -r requirements.txt -r requirements-dev.txt'

@agjohnson Je suis également nouveau sur pipenv, mais si je comprends bien, si vous exécutez seulement pipenv install il ne suivra PAS votre Pipfile.lock , mais examinez plutôt Pipfile , et mettez à niveau tous les packages que vous n'avez pas verrouillés dans la version exacte, puis _update_ Pipfile.lock . C'est donc comme pip-compile et pip-sync (du package pip-tools) combinés. Je pense que c'est un peu déroutant.

Je suppose que le plus correct est de vérifier pipfile.lock, si oui, --ignore-pipfile, sinon non?

Oui, si nous recherchons des builds déterministes, alors le fichier de verrouillage doit être suivi et --ignore-pipfile donné. Je ne sais pas comment cela aurait du sens autrement. Et puis il y a pipenv update , qui désinstalle/installe des packages comme pip-sync mais il n'a pas l'option --ignore-pipfile ... hmm.

Le fichier de verrouillage est spécifique à la machine, il n'a pas les marqueurs (ex « python_version < 3 »), mais les deux devraient fonctionner.

C'est un bon rappel. Ni pip-tools ni pipenv (qui utilise des pip-tools en dessous) ne prennent en charge les fichiers de verrouillage "universels". Donc, si vous créez le fichier de verrouillage sous python 3.6 sur Windows et que vous l'exécutez ensuite sur 3.4 sous Linux, les choses peuvent se casser, car le fichier de verrouillage attend un environnement 3.6/Windows. Voir https://github.com/kennethreitz/pipenv/issues/857 et https://github.com/jazzband/pip-tools/issues/563.

Que signifie ignorer le pipfile pour les projets qui ne vérifient pas leur pipfile.lock

Ces projets n'obtiendront pas de builds déterministes. C'est ok, mais doit être documenté. L'un des principaux avantages de pipenv est d'obtenir des versions déterministes (amélioration par rapport à un simple requirements.txt ), mais comme vous le dites, ce n'est pas une exigence. L'utilisateur doit simplement le reconnaître.

Dans le cas d'un requirements.txt, nous devrions pouvoir utiliser simplement pipenv install au lieu de pip install

Je ne pense pas que pipenv lit les fichiers de style requirements.txt. Au cas où il n'y aurait pas de Pipfile pourquoi ne pas simplement recourir à un ancien comportement ?

C'est un bon rappel. Ni pip-tools ni pipenv (qui utilise des pip-tools en dessous) ne prennent en charge les fichiers de verrouillage "universels". Donc, si vous créez le fichier de verrouillage sous python 3.6 sur Windows et que vous l'exécutez ensuite sur 3.4 sous Linux, les choses peuvent se casser, car le fichier de verrouillage attend un environnement 3.6/Windows. Voir kennethreitz/pipenv#857 et jazzband/pip-tools#563.

Ah oui, il semble donc qu'ignorer le Pipfile et s'appuyer sur Pipfile.lock devrait être une option, mais est désactivé par défaut. Sans fichiers de verrouillage universels, nous ne pouvons pas garantir que l'environnement est le même système d'exploitation ou même la même version python que nos images de construction.

Je ne pense pas que pipenv lit les fichiers de style requirements.txt. S'il n'y a pas de Pipfile, pourquoi ne pas simplement recourir à un ancien comportement ?

Il semble que si un Pipfile est manquant et qu'un requirements.txt est disponible, pipenv install traduira automatiquement en Pipfile. De même, si le fichier est nommé foo.txt , pipenv install -r foo.txt récupérera le fichier nommé arbitrairement. Ce sont les deux modes que nous devons prendre en charge sur RTD.

Cela ne change pas de requirements.txt, cela peut être reproductible ou non, selon le travail du programmeur... Je ne m'embêterais pas, utilisez simplement le --dev , car la plupart du temps ReadTheDoc est déclenché en même temps que Travis.

Plus tard, lorsque le fichier de verrouillage universel sera réglé, cela pourra être adapté à Rtd, mais ce n'est pas aussi "important" que dans la version travis (car l'artefact est la doc, pas la roue réelle), et nous n'avons pas cette capacité dans le travis.

Ou, plus simple, vous laissez le développeur écrire sa ligne d'installation ( pip install -r requirements.txt , ou pipenv install --dev ), c'est la solution la plus polyvalente.

Quel est le statut de ce problème ? Peut-être qu'il y a quelque chose que je peux aider?
Merci!

Salut les gars.
Y a-t-il des nouvelles?

Aucune mise à jour. N'hésitez pas à reprendre ce travail si vous le souhaitez.

Salut les gars, tout d'abord, merci pour tout le travail que vous faites sur ce projet :smiley:

Je me suis intéressé à ce problème et j'aimerais juste noter quelques éléments sur la façon dont nous nous attendons à ce que les gens utilisent cette fonctionnalité et sur les cas d'utilisation que nous devrions prendre en compte. Les gens sont souvent confus quant à la façon dont pipenv doit être utilisé, et je m'attends donc à ce qu'il soit difficile de plaire à tout le monde avec cette fonctionnalité.

Je vais utiliser les informations fournies dans cette section de la documentation de pipenv comme point de référence principal. L'adaptation aux cas d'utilisation et aux directives qui y sont répertoriées devrait satisfaire la plupart des développeurs.

Processus d'installation de RTD

Donc actuellement, il y a trois étapes dans le processus d'installation après la création de virtualenv :

1. Installation des exigences de base de RTD
2. Installation des exigences utilisateur à partir d'un fichier requirements.txt avec pip (étape facultative)
3. Installation du package lui-même avec pip install . ou python setup.py install --force (également facultatif)

Comment pipenv s'intègre dans ces étapes

L'installation de pipenv elle-même doit être effectuée dans la première étape. Je pense que cela devrait être conditionnel en fonction de la configuration YAML.

Maintenant, certaines (ou peut-être même "la plupart") utilisations de pipenv combineraient en fait les étapes deux et trois, car de nombreux projets ont -e . ou une spécification équivalente dans leur Pipfile (et par la suite leur Pipfile.lock, qui serait également contiennent des sous-dépendances du package).

Cependant, comme spécifié dans la documentation liée ci-dessus, les Pipfiles sont également capables de gérer les dépendances par eux-mêmes sans compter sur les install_requires . Dans ce cas, pipenv serait utilisé pour terminer l'étape 2, et pip install . ou python setup.py install pour l'étape 3, si nécessaire.

L'approche la plus simple et la plus malléable à laquelle je puisse penser consiste à faire pipenv install {opts} comme étape supplémentaire entre 2 et 3. Étant donné que les étapes 2 et 3 sont déjà facultatives, cela donne à l'utilisateur beaucoup de liberté pour la façon dont il souhaite configurer l'environnement, sans confondre l'utilisateur avec des options de configuration mutuellement exclusives. La documentation devrait évidemment être assez claire sur la façon dont ces diverses options de configuration peuvent être utilisées ensemble.

Arguments à pipenv install

Je pense que dans l'intérêt de donner à l'utilisateur la liberté et également de pérenniser la configuration de tout nouveau drapeau pipenv install , nous devrions simplement permettre à l'utilisateur de spécifier les drapeaux qu'il aimerait utiliser comme chaîne dans le YAML , cependant nous devrions avoir --system défini comme indicateur persistant pour garantir que pipenv ne crée pas un autre virtualenv. L'utilisation de pipenv pour gérer les environnements virtuels n'est pas nécessaire car nous avons déjà une belle conception robuste et une API pour configurer des environnements virtuels avec virtualenv , et la gestion de l'environnement virtuel de pipenv est plus d'une fonctionnalité de qualité de vie de l'utilisateur final.

Je pense que --ignore-pipfile est inutile car le comportement par défaut est d'installer à partir de Pipfile.lock .

Cependant, dans tous les cas, je pense que nous ne devrions pas spécifier de packages ou de fichiers d'exigences comme arguments pour pipenv install , car cela est utilisé pour ajouter des dépendances à un Pipfile et non pour recréer de manière déterministe un environnement de développement.

Disposition de la configuration

Donc, étant donné les points ci-dessus, je pense que mon approche serait d'ajouter ces options au YAML :

pipenv_install: True|False
pipenv_install_opts: OPTIONS

Edit : En second lieu, il serait peut-être préférable d'avoir ces options en tant que sous-clés sous une clé pipenv .

La raison pour laquelle je ne l'inclus pas dans la clé python est que je pense qu'elle devrait être au même niveau que la clé requirements_file , à laquelle elle ressemble le plus.

Résumé de l'installation avec pipenv

1. Installez les exigences de base de RTD avec pip, y compris pipenv si pipenv_install est True
2. Installez éventuellement les exigences à partir d'un fichier requirements.txt avec pip
3. Faites éventuellement pipenv install --system {opts}
4. Faites éventuellement soit pip install .[extras] ou python setup.py install --force , soit ni l'un ni l'autre

Merci de me faire savoir si vous avez un avis différent et/ou signalez des améliorations qui pourraient être apportées :smiley:

@Tobotimus merci, c'est un excellent résumé du cas d'utilisation de pipenv, actuellement, nous faisons une v2 du fichier de configuration https://github.com/orgs/rtfd/projects/2 , je pense que cela devrait être là.

@stsewd Ah je vois ! Super. Malheureusement, ce lien est un 404 pour moi, et je ne vois aucun projet sur la page d'organisation de rtfd, mais j'ai trouvé le jalon d'achèvement du fichier YAML , que je suis heureux d'aider quand j'aurai un peu de temps :smile: I suis un nouveau ici donc encore quelque peu trébucher.

J'ai ouvert #4254 en tant que correctif pour l'ancienne configuration, mais je suis plus qu'heureux de le refactoriser en fonction de toute nouvelle spécification. Existe-t-il une branche de fonctionnalité quelconque pour la nouvelle configuration ? Merci!

Nous déplaçons le référentiel rtd-build vers le référentiel readthedocs.org https://github.com/rtfd/readthedocs.org/pull/4242 , il y a quelques idées ici https://docs.readthedocs.io/en/latest /design/yaml-file.html et c'est en quelque sorte le schéma de base que nous avons pour la v2 https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/fixtures/spec/v2/schema .yml. Il y a des décisions de conception à prendre.

Merci beaucoup, je suppose que mon approche de #4254 pourrait facilement s'adapter à ce schéma en plaçant simplement la section pipenv sous la clé python . Pour référence, voici le patch que j'ai préparé pour le repo rtd-build . Je suppose que j'attendrai que le #4242 soit fusionné et que l'analyseur de configuration V2 progresse davantage avant de continuer avec pipenv PRs :smiley:

Il y a plus de travail pour terminer le processus de portage, il serait donc probablement préférable d'attendre que ce processus soit terminé en premier. Je suppose que nous pouvons considérer readthedocs_build gelé pour le moment.

Une fois que les choses sont portées, vous pouvez retravailler vos relations publiques pour qu'elles soient hébergées ici.

Pour l'instant, un PR séparé qui met à jour notre fichier de spécifications de schéma v2 serait le meilleur moyen de commencer. Vous trouverez les tests et le schéma ici :
https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/fixtures/spec/v2/schema.yml
https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/tests/test_build_config.py

Ce serait le meilleur endroit pour décrire vos changements et la justification des changements de schéma.

Le retour immédiat que j'aurais est que je n'aime pas exposer un pipenv.options , nous ne le faisons pas pour d'autres outils, nous prenons plutôt en charge des options spécifiques. Je suis d'accord que tout cela devrait être sous une clé python.pipenv , mais peut-être que nous devons également changer python.install pour prendre en charge pipen au lieu de pip .

Edit : cc @Tobotimus , aussi 🎉 pour la contribution ! Désolé votre atterrissage de relations publiques en plein milieu d'un grand projet

@agjohnson Merci pour l'info ! Et aussi merci pour les retours. Je peux comprendre qu'exposer pipenv.options est incompatible avec le reste du schéma.

Je suppose que dans ce cas, les options spécifiques que nous devrions prendre en charge pour le moment seraient simplement --dev (installer les dépendances de développement). Quant aux autres options :

• --skip-lock n'a aucun sens pour moi pour les gens car cela rend les dépendances vagues, ce qui va à l'encontre de l'objectif de l'outil.
• --ignore-pipfile nous pourrions ajouter comme persistant, cela ne ferait pas de différence 99% du temps puisque pipenv install par lui-même s'installe toujours à partir de Pipfile.lock moins qu'il ne soit obsolète avec le Pipfile .
• --system doit rester persistant pour s'assurer que nous ne créons pas un nouvel environnement virtuel.

De plus, je ne pense pas que python.install doive être modifié car dans une fraction significative des cas, pipenv n'est pas réellement un remplacement pour pip, mais un remplacement pour python.requirements , dans auquel cas certains utilisateurs voudraient à la fois une étape pipenv install et une étape pip install . .

Super, d'accord. Il semble que --dev soit le principal que nous devrions prendre en charge pour le moment.

Quand j'ai commencé à travailler là-dessus, j'ai juste supposé que nous pouvions traiter pipenv en remplacement de pip . Avez-vous des exemples de packages qui utilisent un workflow avec à la fois une étape pip et pipenv ? Je suis juste curieux de savoir à quoi cela ressemble réellement.

L'ajout d'une étape pipenv, par opposition au remplacement de l'étape pip, n'est pas incorrect. Sans en savoir beaucoup sur la conda, c'est peut-être aussi ainsi que nous devrions traiter la conda.

En toute honnêteté, je n'ai pas d'exemple de package qui utilise ce workflow, j'ai juste basé mes exemples de cas d'utilisation sur cette section de la documentation de pipenv pour être aussi impartial que possible vis-à-vis de ma propre utilisation (qui est d'avoir pipenv installe le projet lui-même à partir du Pipfile.lock, remplaçant ainsi pip ). En particulier, ce workflow :

Pour les applications, définissez les dépendances et où les obtenir dans le _Pipfile_ et utilisez ce fichier pour mettre à jour l'ensemble des dépendances concrètes dans Pipfile.lock . Ce fichier définit un environnement idempotent spécifique qui est connu pour fonctionner pour votre projet. Le Pipfile.lock est votre source de vérité. Le Pipfile est une commodité pour vous de créer ce fichier de verrouillage, en ce sens qu'il vous permet de rester encore quelque peu vague sur la version exacte d'une dépendance à utiliser.

Ce workflow ne mentionne pas l'utilisation de pipenv pour installer le package lui-même.

Cependant, après un peu plus de recherches, ce flux de travail est peut-être plus orienté vers des projets qui ne sont pas réellement installables par pip. Pour citer le Python Packaging User Guide lorsqu'ils comparent pipenv à poetry :

pipenv évite explicitement de supposer que l'application sur laquelle on travaille et qui dépend des composants de PyPI prendra elle-même en charge la distribution en tant que pip -package Python installable.

Vous avez donc probablement raison de dire que traiter pipenv en remplacement de pip serait suffisant :smiley:

Salut @agjohnson. J'utilise principalement pipenv dans toutes mes applications python (ainsi que mes librairies grâce à PBR). Pour l'instant j'en suis très content, et j'ai développé un petit package qui génère un requirements.txt pour que readthedoc soit content même s'il ne supporte pas Pipfile pour le moment.

Vous pouvez trouver un emporte-pièce qui amorce tout cela pour les nouveaux projets : compatible readthedocs, pipenv, etc.

Donc, si je pouvais m'en débarrasser si ReadTheDocs prend en charge de manière transparente Pipfile (et pipenv), j'en serais très heureux.

TD ; DR : pipenv est principalement destiné aux applications, pas aux bibliothèques. Mais readthedocs pour l'application utilisant pipenv serait génial !

Bien sûr, il devrait utiliser le "--dev", je pense même que cela devrait être par défaut. La question sur le fichier de verrouillage est délicate, je n'ai pas d'avis clair là-dessus. Je le laisserais facultatif par l'utilisateur :

• en utilisant un fichier de verrouillage, assurez-vous que la construction est reproductible, cela devrait être une exigence pour les bibliothèques et l'application
• mais pour une bibliothèque, nous ne devrions pas verrouiller les dépendances du package, afin que pip résolve les versions des dépendances sur pip install mydeps

Ma solution pour le moment est de ne pas suivre le fichier de verrouillage des bibliothèques, mais cela rend mes builds non reproductibles. Je ne suis pas heureux mais je peux vivre avec.

Si vous détectez un Pipfile dans le projet en cours, ajoutez simplement pip install au début de tous vos pipenv run comme par exemple : pipenv run pip install sphinx sphinx-rtd-theme . N'essayez pas d'utiliser pipenv install , c'est inutile et risqué car cela lance le résolveur

Y a-t-il une mise à jour à ce sujet ? Semble-t-il que cela devrait être haut sur le radar? Cela m'empêche vraiment d'utiliser readthedocs car je ne veux pas pirater la base de code, puis ne pas pouvoir obtenir de mises à jour.

@petersmithca c'est sur notre radar, nous essayons d'abord de terminer la v2 du fichier de configuration et de mieux comprendre le flux de travail des projets utilisant un pipfile. Toute aide/commentaire sur le workflow souhaité est le bienvenu.

Peut-être un malentendu, mais essentiellement mon flux de travail remplace essentiellement la création de virtualenv et pip install -r requirements.txt par pipenv install et toute activation de l'environnement avec pipenv shell

@petersmithca Plutôt que pipenv install j'utiliserais plutôt pipenv sync --dev . Je mets normalement les dépendances liées à la génération de documentation et aux tests dans la section "dev" du Pipfile. De plus, sync s'assurera que les packages installés correspondent à ceux définis dans le Pipfile.lock , bien que, si ce fichier n'existe pas, alors pipenv install --dev aurait du sens.

Je n'avais pas utilisé la synchronisation auparavant, mais je suis d'accord avec le --dev, j'ai également mis le
docs sous mon dev, j'ai juste oublié ça

Le mer. 29 août 2018 à 13:59 Miguel Sánchez de León Peque <
[email protected]> a écrit :

@petersmithca https://github.com/petersmithca Plutôt que d'installer pipenv
J'utiliserais plutôt pipenv sync --dev. Je mets normalement des dépendances
liés à la génération de documentation et aux tests dans la section "dev" dans
le Pipfile. De plus, la synchronisation s'assurera que les packages installés correspondent à ceux
défini dans le Pipfile.lock, bien que, si ce fichier n'existe pas, alors pipenv
install --dev aurait du sens.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/rtfd/readthedocs.org/issues/3181#issuecomment-417027482 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AE1F_bRgPmEc1uydCZKtJtT95vwIua_Eks5uVshbgaJpZM4QDCg9
.

prefere pipenv install --ignore-pipfile --dev pour forcer l'utilisation du fichier de verrouillage.

À propos de l'utilisation de pipenv en remplacement de venv/virtualenv, en fait, nous pouvons toujours les utiliser.

À partir de la documentation pipenv

Par défaut, Pipenv essaie de détecter s'il est exécuté dans un environnement virtuel et le réutilise si possible. C'est généralement le comportement souhaité et permet à l'utilisateur d'utiliser n'importe quel environnement créé par l'utilisateur avec Pipenv.

Donc, nous pouvons probablement traiter pipenv comme une autre méthode d'installation (comme pip ou setup.py)

Je teste pipenv maintenant, j'ai trouvé ceci:

• --ignore-pipfile essaiera de générer un fichier de verrouillage s'il n'en trouve pas.
• Lors de l'exécution de pipenv install , il générera un fichier de verrouillage.
• Lors de l'exécution avec --skip-lock il s'installera à partir du fichier pip, sans générer de verrou

Si une erreur se produit lors de la génération du fichier de verrouillage, il n'installe pas les dépendances (il peut échouer s'il existe des dépendances incompatibles).

Ainsi, les personnes utilisant un dep non piné (comme les bibliothèques) peuvent avoir ce problème, devrait-il être un problème à résoudre par les utilisateurs ? Ou faut-il mettre les deux options ? --ignore-pipfile et --skip-lock ? ( --ignore-pipfile sera activé par défaut)

Pipenv ne prend pas en charge la spécification d'un Pipfile personnalisé (nous prévoyons de prendre en charge les installations à partir d'un autre répertoire que roo). Donc, je prévois de mettre cela en tant que variable d'environnement, la commande ressemble à ceci

 PIPENV_PIPFILE=./custom/path/Pipfile pipenv install --system --dev --ignore-pipfile --skip-lock 

--skip-lock et --ignore-pipfile sont des options sur le fichier yaml, --ignore-pipfile est activé par défaut. De plus, --dev est une option et est désactivé par défaut.

Avec cela, nous installons les dépendances dans le même environnement virtuel. J'utilise une configuration comme celle-ci pour ce projet https://github.com/gsemet/cfgtree :

version: 2
sphinx:
  configuration: docs/conf.py
python:
  install:
    - pipfile: .
      skip_lock: true
      dev: true
    - path: .
      method: pip

Salut les gens, je teste le support pipfile sur rtd, pouvez-vous s'il vous plaît commenter un projet qui utilise un pipfile (et a des documents à construire) ? Cela m'aidera beaucoup sur les tests et apportera une implémentation moins boguée p:

https://github.com/dls-controls/pytac utilise Pipenv, possède un fichier pip, mais possède également un fichier rtd-requirements.txt à cette fin précise. C'est sur https://pytac.readthedocs.io/en/latest/.

Merci d'avoir regarder ceci!

C'est le rôle de pipenv-to-requirements/ :)

@willrogers J'ai pu créer vos documents avec l'implémentation actuelle, merci !

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour vos contributions.

@stsewd Des mises à jour à ce sujet ? :rougir:

Désolé pour le bot, ce n'est pas périmé. Nous ne sommes bloqués que par https://github.com/rtfd/readthedocs.org/pull/4740 , qui n'a besoin que d'un autre examen. Ensuite, nous pouvons fusionner https://github.com/rtfd/readthedocs.org/pull/4783 en plus de cela. Nous sommes assez proches de sortir cette fonctionnalité.

Salut à tous, y a-t-il une mise à jour à ce sujet? On dirait que #4740 a été fusionné, donc #4783 peut-il également être fusionné ? J'attends vraiment cette fonctionnalité avec impatience.

Est-ce toujours dans les plans ? Mon travail utilise exclusivement pipenv. Et sans son support, j'ai besoin de construire un hack pour faire fonctionner les choses

@stsewd Vous avez mentionné précédemment que nous devrions commenter les projets exécutés sur pipenv. Je maintiens https://github.com/pyvec/docs.pyvec.org et https://github.com/honzajavorek/cojeapi.

Les deux exigent actuellement que les développeurs de la documentation exécutent pipenv lock --requirements > requirements.txt chaque fois qu'ils perturbent les dépendances. Bien que nous ayons CI pour vérifier que ce fichier n'est pas désynchronisé, il est ennuyeux de travailler avec. Je ne sais pas s'il existe une meilleure solution de contournement pour le moment - je serais heureux si quelqu'un avait une suggestion qui conduirait à un flux de travail plus fluide.

(Si quelqu'un est intéressé par le linter, consultez ce script . Fonctionne correctement avec dependabot .)

Salut tout le monde, désolé pour le silence ici. Nous essayons de décider si le support pipenv ou non.

• Une chose est que pipenv n'adopte pas (ou n'adoptera pas) le PEP 517 https://github.com/pypa/pipenv/issues/2787#issuecomment -416685889 comme d'autres outils comme la poésie ou flit l'ont fait (cela nous permet d'appeler simplement pip et n'implémentez pas plus d'options dans le fichier de configuration).
• La dernière version de pipenv était il y a un an https://pypi.org/project/pipenv/#history , nous ne sommes pas sûrs de la direction que le projet va prendre.
• Pipenv est lent lors de la résolution des deps, nous avons déjà le même problème avec conda. Mais conda a fait une amélioration récemment, donc pipenv pourrait également avoir des améliorations dans ce domaine au fil du temps.
• Nous pouvons essayer de prendre en charge pipenv de manière expérimentale (nous avons déjà une sorte de PR prêt avec le support de pipenv), nous pouvons donc le supprimer/le modifier sans aucune garantie.

Une partie de ces décisions est que si nous implémentons pipenv, nous devrons le maintenir pour toujours. Merci de nous faire part de vos avis.

Personnellement, j'ai arrêté d'utiliser Pipenv (en utilisant toujours Conda et Poetry). Je pense qu'aller avec PEP 517 peut être le meilleur choix.

Pipenv est toujours la meilleure option prise en charge. Les éditeurs comme pycharm et spacemacs prennent en charge pipenv. Dependabot prend en charge pipenv. Le seul outil que j'utilise qui ne prend pas en charge pipenv est readthedocs.

Je n'ai aucune idée de ce qui va se passer dans le futur. Le fait que pipenv n'ait pas été mis à jour depuis plus d'un an ne semble pas bon pour pipenv. Je vois que la poésie[1] et le flit[2] sont activement maintenus. Pip lui-même pourrait être amélioré .

Cependant, pour le moment, je pense que pipenv, qu'on le veuille ou non, est la meilleure option, et même s'il est remplacé à l'avenir, je soupçonne qu'il sera utilisé par les projets hérités pendant longtemps.

Personnellement, plus tôt la communauté Python choisira la solution préférée pour résoudre les problèmes dans les installations pip basées sur requirements.txt , mieux ce sera. Sinon, des outils tels que readthedocs peuvent tous devoir prendre en charge un certain nombre de solutions différentes, car tout choisit une solution différente pour leurs projets.

Remarques:

[1] J'ai récemment essayé la poésie et j'ai découvert qu'elle n'avait pas un bon moyen de migrer à partir d'un système existant basé sur requirements.txt - cependant, si la poésie était la voie de l'avenir, cela pourrait être facilement corrigé. poésie+dépendances n'est pas particulièrement léger - ce qui est important lors de l'installation à la volée pour les exécutions CI.

[2] Pas familier avec flt - je suppose que je devrais jeter un œil.

Dans ce cas, est-il prévu de soutenir la poésie ? Actuellement, je ne peux pas utiliser
le produit avec Pipenv ou Poetry à moins que je pirate le repo localement, puis
bien sûr, il est écrasé à chaque mise à jour.

Le mar. 26 novembre 2019 à 14:04 Santos Gallegos [email protected]
a écrit:

Salut tout le monde, désolé pour le silence ici. Nous essayons de décider si
support pipenv ou non.

• Une chose est que pipenv n'adopte pas (ou n'adoptera pas) PEP 517 pypa/pipenv#2787
  (commenter)
  https://github.com/pypa/pipenv/issues/2787#issuecomment-416685889
  comme d'autres outils comme la poésie ou le flit (cela nous permet d'appeler simplement pip
  et n'implémentez pas plus d'options dans le fichier de configuration).
• La dernière version de pipenv était il y a un an
  https://pypi.org/project/pipenv/#history , nous ne savons pas quoi
  direction que va prendre le projet.
• Pipenv est lent lors de la résolution des deps, nous avons déjà le même problème
  avec conda. Mais conda a fait une amélioration récemment, donc pipenv aurait pu
  améliorations dans ce domaine au fil du temps aussi.
• Nous pouvons essayer de supporter pipenv de manière expérimentale (nous avons déjà
  une sorte de PR prêt avec le support de pipenv), nous pouvons donc le supprimer / le modifier sans
  toute garantie.

Une partie de ces décisions est que si nous mettons en œuvre pipenv est quelque chose qui
nous devrons maintenir pour toujours. Merci de nous faire part de vos avis.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/readthedocs/readthedocs.org/issues/3181?email_source=notifications&email_token=ABGUL7JZGO2MZLY7WMZJ6X3QVVQJJA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVREXG43UVBJ221KLNMV5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVREXG43XVBJ221KLNMV5
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ABGUL7JU6HHROEZP6IWAE3TQVVQJJANCNFSM4EAMFA6Q
.

Dans ce cas, est-il prévu de soutenir la poésie ?

@petersmithca Vous devriez pouvoir utiliser la poésie maintenant https://poetry.eustace.io/docs/pyproject/#poetry -and-pep-517

Je voulais dire que je lirais la doc travailler avec de la poésie pour construire ma documentation.

Le mercredi 27 novembre 2019 à 11h18 Santos Gallegos [email protected]
a écrit:

Dans ce cas, est-il prévu de soutenir la poésie ?

Vous devriez être capable d'utiliser la poésie maintenant
https://poetry.eustace.io/docs/pyproject/#poetry-and-pep-517

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/readthedocs/readthedocs.org/issues/3181?email_source=notifications&email_token=ABGUL7P7B5C5HSU4DDSMDNTQV2FTBA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63ZEF2WWNGWH2WWH2EAMFA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBJGOKLNMVXNG
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ABGUL7KI4LUTHYUITCB7YYLQV2FTBANCNFSM4EAMFA6Q
.

Je voulais dire que je lirais la doc travailler avec de la poésie pour construire ma documentation.

Oui, on n'appelle pas la poésie directement, mais ça s'appelle avec pip (c'est PEP 517)

Ah d'accord. cool merci

Le mercredi 27 novembre 2019 à 11h22 Santos Gallegos [email protected]
a écrit:

Je voulais dire que je lirais la doc travailler avec de la poésie pour construire ma documentation.

Oui, on n'appelle pas la poésie directement, mais ça s'appelle avec pip (c'est PEP
517)

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/readthedocs/readthedocs.org/issues/3181?email_source=notifications&email_token=ABGUL7M2WA2SR2JL54AIIG3QV2GEPA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN5MVXH22CA
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ABGUL7OXN4AK63UAIL7TO3LQV2GEPANCNFSM4EAMFA6Q
.

Je crois comprendre que pip va commencer à prendre en charge les formats Pipfile et Pipfile.lock à un moment donné dans le futur. Quoi qu'il en soit, je trouve que la gestion des dépendances avec Pipenv est plus intuitive et fiable qu'avec pip, et j'aime le venv intégré.

@zbeekman Avez-vous une source pour cette compréhension ?

Merci pour toutes les contributions jusqu'à présent, tout le monde. C'est utile d'avoir.

Sinon, des outils tels que readthedocs peuvent tous devoir prendre en charge un certain nombre de solutions différentes, car tout choisit une solution différente pour leurs projets.

Je ressens la même chose dans une certaine mesure. RTD a peut-être trop d'opinions sur les processus et les outils, mais si nous cherchons à soutenir la communauté Python dans son ensemble, nous devrions probablement avoir plus de flexibilité dans notre flux de travail.

Une option que j'ai soulevée, et cette option n'est pas activement envisagée pour le moment, consiste à implémenter la prise en charge de pipenv en tant que fonctionnalité "expérimentale". Cela signifierait que pipenv n'est pas pris en charge par l'équipe principale (nous ne pouvons pas aider avec les demandes de support), et le support de pipenv pourrait disparaître (bien que nous le désapprouvions avec des avertissements).

Normalement, je voterais probablement en faveur de la prise en charge de pipenv à ce stade, mais il s'agit toujours d'une fonctionnalité très demandée - même compte tenu de certains des arguments contre pipenv.

La question à laquelle je pense que l'équipe principale a besoin de plus de réponses, si vous êtes un utilisateur de pipenv, est "pourquoi ne pas utiliser de la poésie ?". Nos décisions sur pipenv pourraient être encore plus faussées parce que nous n'utilisons aucun de ces outils dans le développement quotidien, donc la poésie est synonyme de pipenv - seul RTD prend en charge la poésie.

L'une des raisons pour lesquelles j'ai commencé à utiliser pipenv (et non la poésie) à l'époque était une prise en charge plus large de Pipfile dans les intégrations - par exemple dependabot, GitHub (avertissements de sécurité), Snyk, Heroku ou now.sh prend en charge Pipfile pour spécifier les dépendances avec requirements.txt , tandis que la prise en charge de pyproject.toml et de la poésie est encore rare. La dernière fois que j'ai vérifié, j'ai remarqué que dependabot le supporte maintenant, mais je doute des autres. RTD était en fait le seul endroit où je devais trouver des hacks pour Pipfile, et où la poésie est prise en charge plus tôt.

Je ne sais pas quel outil gagne les utilisateurs à la fin, mais pour moi, j'ai l'impression que les gens voulaient désespérément avoir quelque chose comme pip + virtualenv et quand pipenv est apparu, ils ont sauté sur l'utiliser. La poésie n'était pas très connue et quand j'en ai entendu parler, j'ai eu l'impression que c'était une distraction d'avoir enfin un outil pour gouverner l'écosystème. Plus tard, les gens ont réalisé les défauts de pipenv et ont commencé à revenir à pip ou à chercher des alternatives, à découvrir la poésie. J'ai l'impression que ce processus est toujours en cours. L'outillage rattrape la poésie remarquée, mais pipenv a été adopté en masse plus tôt et est déjà pris en charge «partout».

Aujourd'hui, comme beaucoup, je vois les limites de pipenv et je pense migrer vers la poésie, mais je ne le ferai pas tant que l'outillage que j'utilise ne me rattrapera pas.