Pipenv: Comment garder setup.py install_requires et Pipfile en synchronisation

Pipenv a-t-il une API python qui pourrait être utilisée ? Je mets à jour manuellement la liste pendant que je travaille sur un projet, mais ce qui suit pourrait être sympa :

from setuptools import setup
from pipenv import find_install_requires

setup(
    # ...
    install_requires=find_install_requires()
    # ...
)

la fonction a juste besoin de retourner une liste des clés dans la section pipfiles [packages]. J'imagine que vous pourriez obtenir cette fonctionnalité en utilisant déjà une fonction d'assistance, mais ce serait bien si cela faisait partie de pipenv afin que nous n'ayons pas tous à l'implémenter.

Pipfile , l'implémentation prenant en charge l'analyse Pipfile de Pipenv, peut vous aider :

import pipfile
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

Mais je ne le recommanderais pas, ou selon Pipenv dans setup.py. L'importation pipenv (ou pipfile ) signifie que l'utilisateur doit réellement l'installer avant d'essayer d'installer votre package, et des outils comme Pipenv essayant d'y jeter un coup d'œil sans l'installer ( setup.py egg_info ) ont gagné ça marche pas. Le setup.py ne devrait dépendre que de Setuptools.

Une solution intermédiaire serait d'écrire un outil similaire à bumpversion qui synchronise automatiquement un fichier texte basé sur Pipfile. Distribuez ce fichier avec votre package et lisez-le dans setup.py. Utilisez ensuite CI ou un crochet de validation pour vous assurer que les fichiers sont toujours synchronisés.

Ouais bon point ignore moi.
Peut-être que "pipenv install" pourrait faire la synchronisation ?

Le lundi 8 janvier 2018 à 17h04, Tzu-ping Chung [email protected]
a écrit:

Pipfile https://github.com/pypa/pipfile , l'implémentation soutenant le
l'analyse, peut aider avec ceci:

importer le fichier pip
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

Mais je ne le recommanderais pas, ou selon Pipenv dans setup.py.
L'importation de pipenv (ou pipfile) signifie que l'utilisateur doit réellement installer
qu'avant d'essayer d'installer votre package, et des outils comme Pipenv essayant de
y jeter un coup d'œil sans installer (setup.py egg_info) ne fonctionnera pas. le
setup.py ne devrait dépendre que de Setuptools.

Une solution intermédiaire serait d'écrire un outil similaire à bumpversion
https://github.com/peritus/bumpversion qui synchronise automatiquement un texte
fichier basé sur Pipfile. Distribuez ce fichier avec votre colis et lisez-le
dans setup.py. Ensuite, utilisez CI ou un crochet de validation pour vous assurer que les fichiers sont toujours
en synchronisation.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
.

@uranusjr vient de tester mes hypothèses ici, mais ne serait-il pas possible d'ajouter pipenv au setup_requires de setup.py et de retarder l'importation de pipenv dans une commande setuptools? Ou est-ce considéré comme une mauvaise pratique ?

@Korijn Ce n'est peut-être pas en soi, mais étant donné que la meilleure pratique actuelle consiste à utiliser des virtualenvs séparés pour chaque projet Python, cela obligerait l'utilisateur à installer une copie de Pipenv pour chaque projet, ce qui n'est pas très intuitif. Pipenv ne doit être installé qu'une seule fois (généralement globalement) et est utilisé en dehors du virtualenv du projet pour le gérer, et non à l'intérieur du virtualenv du projet.

Alors, quelle est la solution à cela qui a conduit à la fermeture du problème ? N'y a-t-il aucun moyen de garder une trace des dépendances dans le Pipfile et dans setup.py ? Existe-t-il une meilleure pratique qui contourne le problème ?

Pour les applications déployées ou distribuées dans des programmes d'installation, j'utilise simplement Pipfile.

Pour les applications distribuées sous forme de packages avec setup.py, je mets toutes mes dépendances dans install_requires.

Ensuite, je fais dépendre mon Pipfile de setup.py en exécutant pipenv install '-e .' .

[Mise à jour 2019-08-23] Je garde les packages de développement dans Pipfile de nos jours, seules les dépendances d'exécution peuvent vivre dans setup.py.

Je pense que l'approche de @ Korijn est la meilleure pratique ici. Pipfile (et requirements.txt) est pour les applications ; setup.py est pour les packages. Ils servent à des fins différentes. Si vous avez besoin de les synchroniser, vous vous trompez (IMO).

@uranusjr Pas selon la documentation.

Pipenv est un outil qui vise à apporter le meilleur de tous les mondes du packaging (bundler, composer, npm, cargo, yarn, etc.) au monde Python. Windows est un citoyen de première classe dans notre monde.

Il crée et gère automatiquement un environnement virtuel pour vos projets, ainsi qu'ajoute/supprime des packages de votre Pipfile lorsque vous installez/désinstallez des packages. Il génère également le toujours important Pipfile.lock, qui est utilisé pour produire des versions déterministes.

Peut-être que je ne comprends pas. Pourriez-vous développer votre déclaration s'il vous plaît?

La façon dont je l'ai compris est que pipenv est un système complet de gestion des dépendances similaire à composer pour PHP, mais je commence à réaliser que ce n'est pas le cas. Surtout que pipenv n'installera pas les dépendances d'une dépendance qui a un Pipfile et Pipfile.lock, mais pas d'install_requirements dans setup.py.

@vascowhite la question que vous posez ne concerne pas pipenv mais plutôt une séparation fondamentale entre les outils d'emballage python. Dans le workflow python, les fichiers setup.py sont utilisés pour déclarer les dépendances d'installation d'un package distribuable. Donc, si j'ai un package comme requests , et que cela dépend des personnes qui ont installé cffi , je déclarerais cela dans mon setup.py pour que lorsque les gens exécutent pip install requests il effectuera également cette installation si nécessaire.

Les fichiers Pip, comme les fichiers d'exigences, ne sont pas destinés à être parcourus de manière récursive. Au lieu de cela, il existe un seul fichier pipfile qui régit toutes les dépendances d'un projet que vous pourriez développer. Le point est que l'ancien flux de travail générait une liste aplatie d'exigences épinglées, tandis que les Pipfiles contiennent des exigences de niveau supérieur et préfèrent les exigences non épinglées lorsque cela est possible. Lorsque vous installez un package, les exigences de ses setup.py sont résolues de manière récursive vers la meilleure correspondance qui correspond également à vos autres exigences.

Donc, si vous voulez savoir pourquoi les Pipfiles ne sont pas résolus de manière récursive, c'est parce que ce n'est tout simplement pas ainsi qu'ils sont utilisés en python. L'exécution pipenv install nécessite finalement une cible pouvant être installée par setuptools , ce qui signifie que ses exigences d'installation seront définies dans son fichier d'installation.

@techalchemy J'étais à mi-chemin d'une réponse similaire avant que la vôtre n'apparaisse 😂 (effacez tout)

Je voudrais également noter que @vascowhite ce que vous demandez n'est en fait pas farfelu. Avec Pipfile et le fichier de verrouillage disponibles, il est possible de réconcilier les deux flux de travail distincts. Dans un monde idéal, Pipfile remplace install_requires de setup.py et est utilisé pour spécifier des dépendances virtuelles, tandis que le fichier de verrouillage est utilisé pour produire un ensemble de dépendances concret basé sur celui-ci, remplaçant requirements.txt.

Le système d'empaquetage de Python, cependant, est loin d'être idéal à l'heure actuelle, et il faudrait beaucoup de nettoyage avant que cela ne se produise. Heck, Pipenv a déjà des difficultés à gérer les dépendances en ce moment (ps pas la faute de personne), cela fonctionnerait probablement à peine sauf pour le plus simple des projets s'il était utilisé comme ça.

L'espoir n'est pas perdu pour autant (du moins pas le mien). De nombreux PEP ont été proposés et mis en œuvre autour de ce problème, et je pense que les choses sont sur la bonne voie avec setup.py et requirements.txt qui évoluent tous les deux vers un format rigide et déclaratif. Avec un écosystème si vaste, les choses doivent bouger lentement (ou voir Python 3.0), mais elles bougent effectivement.

@techalchemy @uranusjr
Merci à vous deux pour vos réponses claires, elles me précisent certaines choses. Il me semble que la documentation indique trop ce que Pipenv est capable de faire et c'est en partie la cause de ma confusion. La majorité de ma confusion est à moi cependant :)

Venant de PHP, j'ai été confus par l'empaquetage en python, Composer est un jeu d'enfant en comparaison. Je trouve Python beaucoup plus facile à développer et j'adore l'utiliser. Espérons que les choses s'améliorent, je suis sûr qu'elles le seront grâce aux efforts de personnes comme vous et Kenneth Reitz.

Si vous vous en tenez à mes conseils mentionnés ci-dessus, vous pouvez parfaitement harmoniser setup.py et pipenv. Pas besoin d'être tout pointilleux. :)

on dirait que je ne suis pas le seul à être confus #1398

Mettez beaucoup mieux que je ne pourrais cependant :)

Je suis venu ici pour des informations sur l'utilisation pipenv avec un setup.py ; ajoutant mes 0,2 cents à la discussion.

J'ai un package python qui ressemble à setup.py :

 setup(                                                                                                     
    name='my-pkg-name',                                                                             
    packages=find_packages(),                                                                              
    install_requires=[...],
    extras_require={
        'develop': ['click']
    },
    entry_points={
        'console_scripts': [
            'my-pkg-name-cmdline = my-pkg-name.cli:tool'
        ]
    }

Comme vous pouvez le voir, j'utilise click dans le point d'entrée du script pour des tâches telles que la construction et le déploiement.

Lorsque j'exécute $ my-pkg-name-cmdline build , je ne trouve pas click installé, car pipenv install --dev installe des packages dans le pipenv virtualenv. J'ai besoin de jouer avec pipenv shell/exit pour que ça marche. On dirait qu'il y a encore des aspérités à ce sujet.

Par conséquent +1 pour ne pas utiliser pipenv pour les packages.

Je pense que vous êtes censé appeler pipenv run my-pkg-name-cmdline build dans ce scénario.

@Korijn Je ne suis toujours pas sûr du bon flux de travail (j'expérimente encore un peu avec pipenv).

Pour l'instant, le flux de travail qui semble fonctionner pour moi est le suivant :

(starting from scratch)
1- pipenv --three
2- pipenv install [--dev]
3- pipenv install -e . (install application locally)
4- pipenv shell (to enter the virtualenv)

Maintenant, je peux exécuter mon script de construction de package click partir de la ligne de commande.

si j'entre dans le virtualenv (étape 4) avant d'installer l'application localement (étape 3), cela ne fonctionne pas.

Peut-être que je dois juste recâbler mon cerveau pour me rappeler que les packages doivent être installés avant pipenv shell (alors que l'utilisation virtualenv vous oblige à installer des packages avec le virtualenv activé).

@apiraino Je pense que vous ne comprenez rien ici. Si vous souhaitez utiliser (importer) le clic dans votre package, vous devez le mettre dans install_requires la place, afin que les personnes (y compris vous-même) qui installent votre package puissent également avoir le clic installé. Le mettre dans extras_require['dev'] signifie qu'il s'agit d'une dépendance facultative, c'est-à-dire que votre paquet peut fonctionner sans lui, mais l'installation de ces extras peut fournir certaines fonctionnalités supplémentaires.

Cette discussion n'a vraiment plus rien à voir avec Pipenv. Je vous suggère de signaler ce problème à un forum plus approprié, tel que StackOverflow ou des listes de diffusion liées à Python.

@Korijn pipenv install '-e .' donne un Pipfile ne reflétant pas les modules répertoriés sous install_requires dans setup.py

C'est toujours le cas pour pipenv 9.0.3.

Comment puis-je générer Pipfile partir des install_requires de mon setup.py ?

ne pas utiliser de guillemets

J'ai arrêté d'utiliser des guillemets. Cependant, je ne reçois pas de Pipfile créé qui inclut les dépenses de la section install_requires de setup.py .

@benjaminweb J'ai été confus par la même chose aujourd'hui. Cependant, je commence à penser que le comportement actuel peut corriger.

@techalchemy mentionné ci-dessus que

Les fichiers Pip contiennent des exigences de niveau supérieur et préfèrent les fichiers non épinglés dans la mesure du possible. Lorsque vous installez un package, les exigences de son fichier setup.py sont résolues de manière récursive en fonction de la meilleure correspondance qui correspond également à vos autres exigences.

Si vous utilisez le flux de travail mentionné dans https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555, lorsque vous exécutez pipenv install '-e .' sur un projet sans Pipfile existant, pipenv génère un nouveau Pipfile avec ce qui suit:

[packages]

"e1839a8" = {path = ".", editable = true}

Dans ce cas, le seul package que vous avez explicitement demandé à installer dans virtualenv est le package lui-même (c'est-à-dire "."), il est donc logique que seul "." est ajouté au ( [packages] ) dans le Pipfile. De même, si vous pipenv install requests , aucune des dépendances install_requires du fichier setup.py des requêtes n'est non plus ajoutée au Pipfile de votre projet.

Cependant, lors de l'étape suivante d'installation du package, les dépendances install_requires seront installées dans le cadre de la résolution des dépendances pour le package .

Notez que contrairement au Pipfile, le Pipfile.lock enregistre toutes les dépendances exactes pour l'ensemble de virtualenv, qui doit inclure les dépendances install_requires verrouillées sur des versions spécifiques. Si vous regardez le Pipfile.lock qui est généré, vous verrez les dépendances install_requires répertoriées.

Il est possible que je ne comprenne pas du tout comment cela devrait fonctionner. Peut-être que @techalchemy ou @uranusjr peuvent confirmer si c'est la bonne façon de penser à cela ?

Votre ligne de pensée rejoint la mienne. Je mentionnerai également qu'avec les récentes avancées de Setuptools et des outils tels que Flit, vous pouvez toujours spécifier les dépendances de votre package sous une belle forme TOML (au lieu des chaînes d'exigences dans setup.py, ce qui n'est certes pas très joli). Vous les spécifiez simplement dans pyproject.toml à la place de Pipfile.

@uranusjr , il semble que ce que vous dites est que Pipfile n'a besoin de répertorier explicitement les dépendances du projet que si elles ne sont pas déjà capturées par un outil d'empaquetage comme Setuptools ou Flit (via setup.py ou pyproject.toml)

Par exemple, si setup.py ressemble à :

install_requires=['A'],
extras_require={
    'dev': ['B'],
},

Ensuite, le Pipfile n'a besoin que de ce qui suit :

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"


[packages]

"e1839a8" = {path = ".", editable = true}


[dev-packages]

"e1839a8" = {path = ".", extras = ["dev"], editable = true}

L'exécution pipenv install installerait la dépendance A pour la production, et pipenv install --dev installerait les dépendances A et B pour le développement.

Si quelqu'un utilise déjà Setuptools ou Flit, y a-t-il une raison pour laquelle des dépendances devraient être ajoutées dans le Pipfile sous [packages] ou [dev-packages] ? En regardant Requests comme exemple, il n'est pas évident pour moi pourquoi les dépendances de développement sont répertoriées explicitement dans Pipfile sous [dev-packages] , mais les dépendances install_requires et test_requirements sont toutes capturées dans la configuration .py.

Il semble que la seule raison pour laquelle vous auriez besoin d'ajouter explicitement des dépendances à Pipfile est si vous n'utilisez pas Setuptools ou Flit. Est-ce correct? Y a-t-il des raisons pour lesquelles ce n'est pas vrai?

Je pense que c'est juste une préférence personnelle. Lister les dépendances de développement dans extras_require[dev] n'est qu'une convention ; dev-packages OTHO est une clé bien définie. extras_require[dev] permettrait également à n'importe quel utilisateur de pip install package[dev] , ce que les responsables pourraient ne pas aimer. Je peux comprendre que les gens préfèrent l'un à l'autre.

Quant à packages , non, il n'y a vraiment pas de scénario plus logique que install_requires IMO. Je suis sûr que les gens trouveront des utilisations créatives.

Pourquoi ce problème est-il clos ?

@JulienPalard c'est fermé pour plusieurs raisons :

1. Les fichiers Pipfiles et setup.py ne sont pas vraiment destinés à être synchronisés, en soi, je pense qu'il y a eu un tas d'articles liés discutant des détails mais tl;dr Pipfile est à peu près équivalent à un niveau supérieur requirements.txt
2. Si vous voulez que votre projet (disons que c'est le répertoire actuel) ait son setup.py résolu dans le virtualenv géré, le flux de travail serait juste pipenv install -e . -- cela met une seule entrée dans votre Pipfile (la racine de niveau supérieur) et le graphique de dépendance résolu dans votre Pipfile.lock , y compris le install_requires résolu. Si vous souhaitez mettre à jour le virtualenv avec le dernier contenu en raison d'un install_requires modifié, vous devez exécuter pipenv update qui est identique à pipenv lock && pipenv sync dans la dernière version.

J'espère que cela est utile !

En fait, ils sont plus similaires que Pipfile est similaire à requirements.txt : requirements.txt spécifie tous les packages de manière plate tandis que Pipfile & setup.py nécessite uniquement les dépendances de niveau d'entrée. Pipfile.lock & requirements.txt contiennent des informations similaires.

J'ai créé un script de synchronisation POC qui peut être implémenté davantage mais qui couvre actuellement notre cas d'utilisation :
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan c'est essentiellement ce que j'ai dit, chacune de ces choses représente une liste de haut niveau de vos dépendances, mais l'une est destinée à _installer une application_ ( setup.py ) et l'autre est destinée à _la développer_ ( Pipfile ).

Dans le premier cas d'utilisation de setup.py , vous avez les mêmes options pour déclarer des dépendances ouvertes ou entièrement épinglées que vous le feriez avec requirements.txt , mais la plupart des gens utilisent ici l'épinglage de dépendances ouvertes. Dans un Pipfile , vous pouvez également spécifier des broches strictes ou lâches, mais il est également recommandé de conserver cela comme une liste _non aplatie_ de votre graphique de dépendance. Encore une fois, je tiens à souligner que ces deux choses sont également tout à fait valables dans les fichiers requirements.txt , c'est pourquoi je mets constamment l'accent sur la séparation des responsabilités entre les applications et les bibliothèques. Vous entendrez cela souligné dans chaque conférence et chaque tutoriel et dans tous les messages diffusés par la PyPA.

Pipfile.lock et requirements.txt ne sont pas la même chose. Vous pouvez générer un requirements.txt valide à partir d'un Pipfile.lock , mais vous ne pouvez pas générer directement un fichier de verrouillage à partir d'un fichier requirements sans utiliser un intermédiaire Pipfile . En effet, un Pipfile.lock représente une fermeture transitive et nécessitera toujours un intermédiaire Pipfile pour effectuer la résolution des dépendances.

En ce qui concerne la question d'origine, il n'y a aucune raison de synchroniser un fichier setup.py avec un Pipfile autrement qu'en incluant simplement le répertoire en question en tant que chemin modifiable. Lorsque vous exécutez pipenv lock , les dépendances dans le fichier setup.py seront automatiquement résolues. Je ne suis pas sûr de votre cas d'utilisation spécifique, @iddan , ou pourquoi vous avez besoin d'un analyseur spécial pour écrire des choses dans le fichier de configuration, mais je suppose que vous voudrez peut-être lire l'article de Donald Stufft sur setup.py vs requirements. txt ou pour faire référence à ce commentaire de l'un de nos responsables sur la distinction et comment elle s'applique spécifiquement à Pipenv.

Mon cas d'utilisation est que chez K Health, nous avons un référentiel avec nos packages internes qui sont des services autonomes et peuvent également être consommés sous forme de packages. Nous aimerions donc partager nos dépendances de niveau supérieur entre les consommateurs de packages et la configuration de développement/déploiement du service. Puisque nous utilisons Pipenv pour gérer nos dépendances, il sera agréable d'obtenir une sortie du Pipfile en tant que setup.py

Cela ressemble à une variante de # 2148 (remplaçant requirements.txt par Pipfile).

Mais cela concerne setup.py

Cette. Publier. Devrait. Pas. Être. Fermé.

Ce problème est clos car

1. Pipenv n'est pas un outil de packaging .
2. Il a été décidé de ne pas inclure de fonctionnalités de packaging dans Pipenv.
3. Il a été clarifié comment vous pouvez utiliser Pipenv pour gérer les dépendances de développement pendant le développement d'un package.
4. Pipfile est un standard ouvert. Il est facile de construire un outil de packaging basé sur le format Pipfile. Le fait que Pipenv décide de ne pas le faire ne prétend pas vous exclure de le faire.

Si vous vous souciez vraiment de cela, s'il vous plaît, fabriquez un outil vous-même. Avec tant d'anticipation dans ce numéro, je pense qu'il ne serait pas difficile de gagner du terrain si vous postez votre solution ici. Et avec traction, PyPA peut le recommander dans le guide des emballages, tout comme Pipenv. Mais vous devez d'abord créer l'outil.

Veuillez également apprendre à vous adresser respectueusement aux mainteneurs du projet. Voir le code de conduite pour référence. Nous sommes heureux d'avoir des discussions productives, mais nous sommes des bénévoles et nous ne sommes pas ici pour simplement obéir à des souhaits individuels. Si vous ne pouvez pas gérer cela, ne vous embêtez pas à poster.

Je recommanderais de verrouiller ce problème pour éviter toute discussion ultérieure. Je pense que le point a été clairement exprimé.

Faites une chose et faites-la bien !

Salut à tous,

@Korijn j'ai lu cette partie où vous expliquiez comment utiliser extra_requires pour synchroniser setup.py avec Pipfile.

J'essayais de faire cela et j'ai remarqué que Pipfile.lock n'a pas les packages extra_require dans la section dev, donc quand vous avez le code source dans un venv vide et que vous faites pipenv install --dev , car Pipfile.lock n'a pas d'exigences extra_require pipenv installe uniquement les packages sur install_require .

setup.py

import os  # noqa: D100
from setuptools import setup, find_packages


def read(fname):
    """Read a file and return its content."""
    with open(os.path.join(os.path.dirname(__file__), fname)) as f:
        return f.read()


setup(
    name='auditor_client',
    version='0.0.0',
    description='Auditor client package',
    long_description=read('README.md'),
    packages=find_packages(exclude=['tests']),
    install_requires=['requests==2.9.1'],
    extras_require={'dev': ['flake8', 'flake8-docstrings', 'pytest', 'coverage', 'tox']},
    setup_requires=["pytest-runner"],
    tests_require=["pytest"]
)

Pipfile

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]
"e1839a8" = {editable = true, path = "."}

[requires]
python_version = "3.6"

[dev-packages]
"e1839a8" = {editable = true, extras = ["dev"], path = "."}

Pipfile.lock

{
    "_meta": {
        "hash": {
            "sha256": "e58b833e497814c83a2f0b93ad21d33a2af8b72721b20e9607a6c9135978422d"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    },
    "develop": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    }
}

ne devrait pas être le comportement correct que Pipfile.lock a suivi les packages de développement extra_require ?

Oui, cela ressemble à un bug/limitation pour moi. Vous devriez déposer un bogue/problème séparé pour cela.

Je pense qu'il y a un problème ouvert dans le tracker à propos de ce problème, bien que je ne puisse pas le localiser pour le moment. Veuillez rechercher les problèmes existants avant d'en ouvrir un. Merci d'avance :)

Ce n'est pas un bogue, vous ne pouvez pas utiliser plusieurs fois la même entrée de base dans un fichier pip. Si vous spécifiez une dépendance dans la section dev ainsi que dans la section par défaut, la section par défaut prévaut quoi qu'il arrive.

Je passerais par mon expérience de pensée normale, mais je n'ai pas le temps pour le moment, alors croyez-moi sur parole, cela pourrait provoquer des conflits de dépendance et des surprises lorsque vous déployez quelque chose et que vous découvrez que votre dépendance de développement cachait un conflit.

@techalchemy alors comment puis-je gérer mes dépendances de développement dans ce cas ? Je veux seulement savoir comment utiliser pipenv correctement

J'y ai pensé pour mon propre projet, et j'ai en quelque sorte réalisé que je n'avais pas vraiment besoin de la distinction packages / dev-packages . Que diriez-vous de lister {editable = true, extras = ["dev"], path = "."} dans packages .

consultez ce package pipenv-setup

Il synchronise le fichier pipfile/lockfile avec setup.py

$ pipenv-setup sync

package e1839a8 is local, omitted in setup.py
setup.py successfully updated
23 packages from Pipfile.lock synced to setup.py

vous pouvez faire $ pipenv-setup sync --dev pour synchroniser les dépendances de développement avec des besoins supplémentaires. ou $ pipenv-setup sync --pipfile pour synchroniser pipfile à la place

et $ pipenv-setup check pour faire des vérifications seulement

une commande pour tous les résoudre 💯

Est-il prévu de fusionner le package pipenv-setup avec pipenv ?

@peterdeme

Est-il prévu de fusionner le package pipenv-setup avec pipenv ?

@uranusjr @techalchemy sur la base de la discussion ci-dessus, je pense que pipenv pourrait avoir une philosophie quelque peu différente. Mais si les responsables sont d'accord, j'aimerais beaucoup soumettre une demande d'extraction et essayer d'intégrer pipenv-setup

Vous pouvez toujours analyser le Pipfile.lock avec le module intégré json . Extrayez les dépendances non-dev pour votre setup.py install_requires .
La clé "default" contient des "dicts" imbriqués du nom du package avec des nombres version et markers .
Vous n'avez pas besoin de compter sur des importations externes.

@ Kilo59 J'ai vu des gens faire ça. Une astuce à mentionner est de ne pas oublier d'inclure Pipfile.lock en tant que data_file dans setup.py (ou de l'inclure dans MANIFEST.in). Et c'est pour le fichier de verrouillage avec des dépendances épinglées. pipfile, d'autre part, n'est pas trivial à analyser, si vous voulez une version sémantique dans Pipfile. La même exigence de dépendance peut apparaître sous plusieurs formes.

Merci @Madoshakalaka votre outil fonctionne bien !

Je suis d'accord avec d'autres pairs que les dépendances de Setup.py sont différentes des dépendances de projet de Pipfile. Néanmoins, disposer d'un moyen programmable de synchroniser ceux-ci sans travail manuel est une excellente fonctionnalité permettant de gagner du temps. En outre, évite les fautes de frappe/erreurs courantes.

Le setup.py noirci était aussi une belle touche :+1: