Pipenv: setup.pyinstall_requiresとPipfileの同期を維持する方法

pipenvには使用できるPythonAPIがありますか？ プロジェクトで作業しているときにリストを手動で更新しますが、次のことが便利な場合があります。

from setuptools import setup
from pipenv import find_install_requires

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

この関数は、pipfiles [packages]セクションのキーのリストを返す必要があります。 すでにヘルパー関数を使用してこの機能を実現できると思いますが、pipenvの一部であると便利なので、全員で実装する必要はありません。

PipenvのPipfile解析をサポートする実装であるPipfileは、これに役立ちます。

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

しかし、私はこれをお勧めしません、またはsetup.pyのPipenvに依存します。 pipenv （またはpipfile ）をインポートすると、ユーザーはパッケージをインストールする前に実際にインストールする必要があり、Pipenvなどのツールはインストールせずにパッケージを覗き見しようとします（ setup.py egg_info ）動作しません。 setup.pyはSetuptoolsにのみ依存する必要があります。

中途半端な解決策は、Pipfileに基づいてテキストファイルを自動的に同期するbumpversionに似たツールを作成することです。 このファイルをパッケージと一緒に配布し、setup.pyで読み取ります。 次に、CIまたはコミットフックを使用して、ファイルが常に同期していることを確認します。

ええ、良い点は私を無視します。
おそらく「pipenvinstall」で同期できますか？

2018年1月8日月曜日午後5時4分、Tzu-​​ping [email protected]
書きました：

Pipfile https://github.com/pypa/pipfile 、実装は
構文解析は、これを助けることができます：

pipfileをインポートする
pf = pipfile.load（ 'LOCATION_OF_PIPFILE'）
print（pf.data ['default']）

しかし、私はこれをお勧めしません、またはsetup.pyのPipenvに依存します。
pipenv（またはpipfile）をインポートすると、ユーザーは実際にインストールする必要があります
あなたのパッケージをインストールしようとする前にそれ、そしてPipenvのようなツールがしようとしている
（setup.py eg_info）をインストールせずに覗いてみると機能しません。 The
setup.pyはSetuptoolsのみに依存する必要があります。

中途半端な解決策は、bumpversionに似たツールを作成することです。
テキストを自動的に同期するhttps://github.com/peritus/bumpversion
Pipfileに基づくファイル。 このファイルをパッケージと一緒に配布し、読んでください
setup.pyで。 次に、CIまたはコミットフックを使用して、ファイルが常に存在することを確認します
同期中。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
。

@uranusjrはここで私の仮定をテストしているだけですが、setup.pyのsetup_requiresにpipenvを追加し、setuptoolsコマンドへのpipenvのインポートを遅らせることはできませんか？ それともそれは悪い習慣と見なされますか？

@Korijnそれ自体ではないかもしれませんが、現在のベストプラクティスでは、Pythonプロジェクトごとに個別のvirtualenvを使用することを考えると、ユーザーはプロジェクトごとにPipenvのコピーをインストールする必要があります。これはあまり直感的ではありません。 Pipenvは一度だけ（通常はグローバルに）インストールする必要があり、プロジェクトのvirtualenv内ではなく、プロジェクトのvirtualenvの外部で使用して管理します。

では、問題の解決につながったこれに対する解決策は何ですか？ Pipfileとsetup.pyの両方の依存関係を追跡する手段はありませんか？ 問題を回避するベストプラクティスはありますか？

インストーラーでデプロイまたは配布されるアプリケーションの場合、私はPipfileを使用します。

setup.pyを使用してパッケージとして配布されるアプリケーションの場合、すべての依存関係をinstall_requiresに配置します。

次に、 pipenv install '-e .'を実行して、Pipfileをsetup.pyに依存させます。

[更新2019-08-23]最近、開発パッケージをPipfileに保持していますが、setup.pyには実行時の依存関係のみが存在します。

ここでは、@ Korijnのアプローチがベストプラクティスだと思います。 Pipfile（およびrequirements.txt）はアプリケーション用です。 setup.pyはパッケージ用です。 それらは異なる目的を果たします。 それらを同期する必要がある場合は、間違っています（IMO）。

@uranusjrドキュメントに準拠していません。

Pipenvは、すべてのパッケージングの世界（バンドラー、コンポーザー、npm、カーゴ、ヤーンなど）の最高のものをPythonの世界にもたらすことを目的としたツールです。 Windowsは、私たちの世界では一級市民です。

プロジェクトのvirtualenvを自動的に作成および管理し、パッケージのインストール/アンインストール時にPipfileからパッケージを追加/削除します。 また、決定論的なビルドを生成するために使用される、これまでになく重要なPipfile.lockを生成します。

たぶん私はそれを取得していません。 あなたの声明について詳しく教えていただけますか？

私が理解したように、 pipenvはPHP用のcomposerに似た完全な依存関係管理システムですが、そうではないことに気づき始めています。 特にpipenvは、PipfileとPipfile.lockを持つ依存関係の依存関係をインストールしませんが、setup.pyにinstall_requirementsはインストールしません。

@vascowhiteあなたが尋ねている質問は、pipenvに関するものではなく、Pythonパッケージツール間の基本的な分離に関するものです。 Pythonワークフローでは、 setup.pyファイルを使用して、配布可能なパッケージのインストール依存関係を宣言します。 したがって、 requestsのようなパッケージがあり、それがcffiをインストールしている人に依存する場合、 setup.pyで宣言して、人がpip install requestsを実行するようにします。

要件ファイルと同様に、Pipfileは再帰的にトラバースされることを意図していません。 代わりに、開発している可能性のあるプロジェクトのすべての依存関係を支配する単一のpipfileがあります。 これのポイントは、古いワークフローが固定された要件のフラット化されたリストを生成したのに対し、Pipfilesはトップレベルの要件を含み、可能な場合は固定されていないことを好むということです。 パッケージをインストールすると、そのsetup.pyの要件が再帰的に解決され、他の要件にも適合する最適なものになります。

したがって、Pipfileが再帰的に解決されない理由を知りたい場合は、それがPythonでの使用方法ではないためです。 pipenv installを実行するには、最終的にsetuptoolsでインストール可能なターゲットが必要です。つまり、セットアップファイルでインストール要件が定義されます。

@techalchemyあなたがポップアップする前に、私は同様の応答の途中でした😂（すべて削除）

また、 @ vascowhiteが求めているのは、実際には風変わりなことではないことにも注意してください。 Pipfileとロックファイルの両方が使用可能であるため、2つの異なるワークフローを調整することができます。 理想的な世界では、Pipfileはsetup.pyのinstall_requiresを置き換え、仮想依存関係を指定するために使用され、ロックファイルはそれに基づいて具体的な依存関係セットを生成するために使用され、requirements.txtを置き換えます。

ただし、Pythonのパッケージングシステムは現時点では理想的とは言えず、これが発生する前に多くのクリーンアップが必要になります。 ちなみに、Pipenvは現在、依存関係の処理にすでに問題を抱えています（psは誰のせいでもありません）。そのように使用された場合、最も単純なプロジェクトでない限り、おそらくほとんど機能しません。

しかし、希望は失われません（少なくとも私のものではありません）。 この問題に関して多くのPEPが提案され、実装されてきました。setup.pyとrequirements.txtはどちらも厳格な宣言型形式に移行しており、順調に進んでいると思います。 エコシステムが非常に大きいため、物事はゆっくりと移動する必要があります（または、Python 3.0を参照）が、実際に移動しています。

@techalchemy @uranusjr
あなたの明確な答えを両方ともありがとう、彼らは私の心の中でいくつかのことをまっすぐにします。 ドキュメントはPipenvが何ができるかを述べすぎているように私には思えますが、それは部分的に私の混乱の原因です。 私の混乱の大部分は私にかかっています:)

PHPから来たので、Pythonでパッケージ化することに混乱しましたが、Composerは比較的簡単です。 私はPythonを開発するのがはるかに簡単で、それを使うのが大好きだと思います。 物事が改善されることを願っています。彼らはあなた自身やケネス・ライツのような人々の努力を与えると確信しています。

上記の私のアドバイスに固執すれば、setup.pyとpipenvの両方を完全に調和させることができます。 すべてを煩わしくする必要はありません。 :)

混乱しているのは私だけではないようです＃1398

私ができるよりもはるかに良いです:)

setup.pyでpipenvを使用する方法については、こちらをご覧ください。 ディスカッションに私の0.2セントを追加します。

setup.pyのようなPythonパッケージがあります。

 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'
        ]
    }

ご覧のとおり、ビルドや展開などのタスクのスクリプトエントリポイントでclickを使用しています。

$ my-pkg-name-cmdline buildを実行すると、 clickがインストールされていません。これは、 pipenv install --devがpipenvvirtualenvにパッケージをインストールするためです。 それを機能させるには、 pipenv shell/exitをいじる必要があります。 これにはまだいくつかの荒いエッジがあるようです。

したがって、パッケージにpipenvを使用しない場合は+1。

そのシナリオでは、 pipenv run my-pkg-name-cmdline buildを呼び出すことが期待されていると思います。

@Korijn正しいワークフローについてはまだわかりません（まだpipenvで少し実験しています）。

今のところ、私にとってうまくいっているように見えるワークフローは次のとおりです。

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

これで、コマンドラインからパッケージビルドclickスクリプトを実行できます。

アプリケーションをローカルにインストールする前にvirtualenv（ステップ4）に入ると（ステップ3）、機能しません。

おそらく、 pipenv shellの前にパッケージをインストールする必要があることを覚えておく必要があります（ virtualenvを使用するには、virtualenvをアクティブにしてパッケージをインストールする必要があります）。

@apiraino私はあなたがここで物事を正しく理解していないと思います。 パッケージでクリックを使用（インポート）する場合は、代わりにinstall_requiresに入れる必要があります。そうすれば、パッケージをインストールする人（自分自身を含む）もクリックインストールできます。 extras_require['dev']に入れるということは、それがオプションの依存関係であることを意味します。つまり、パッケージはそれがなくても機能しますが、これらの追加機能をインストールすると、特定の追加機能を提供できます。

この議論は、もはやPipenvとは何の関係もありません。 この問題を、StackOverflowやPython関連のメーリングリストなど、より適切なフォーラムに持ち込むことをお勧めします。

@Korijn pipenv install '-e .'は、setup.pyのinstall_requiresの下にリストされているモジュールを反映していないPipfile $を生成します

これは、pipenv9.0.3にも当てはまります。

setup.pyのinstall_requiresからPipfileを生成するにはどうすればよいですか？

引用符は使用しないでください

引用符の使用をやめました。 ただし、 setup.pyのinstall_requiresセクションからのdepsを含むPipfileが作成されません。

@benjaminweb今日も同じことで混乱しました。 しかし、私は現在の振る舞いが正しいかもしれないと思い始めています。

上記の@techalchemyは

Pipfileには最上位の要件が含まれており、可能な場合は固定解除することをお勧めします。 パッケージをインストールすると、setup.pyの要件が再帰的に解決され、他の要件にも適合する最適なものになります。

https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555に記載されているワークフローを使用する場合、既存のPipfileがないプロジェクトでpipenv install '-e .'を実行すると、pipenvは次のような新しいPipfileを生成します。以下：

[packages]

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

この場合、virtualenvへのインストールを明示的に要求した唯一のパッケージはパッケージ自体（つまり「。」）であるため、「。」のみが意味をなします。 Pipfileの（ [packages] ）に追加されます。 同様に、 pipenv install requestsの場合、リクエストのsetup.pyからのinstall_requiresの依存関係も、プロジェクトのPipfileに追加されません。

ただし、次にパッケージのインストール手順が実行されると、パッケージの依存関係解決の一部としてinstall_requiresの依存関係がインストールされます。

Pipfileとは異なり、Pipfile.lockは、virtualenv全体のすべての正確な依存関係を記録します。これには、特定のバージョンにロックされたinstall_requires依存関係を含める必要があります。 生成されたPipfile.lockを見ると、 install_requiresの依存関係がリストされていることがわかります。

これがどのように機能するかを完全に誤解している可能性があります。 たぶん@techalchemyまたは@uranusjrは、これがこれについて正しい考え方であるかどうかを確認できますか？

あなたの考え方は私のものと一致します。 また、最近のSetuptoolsの進歩やFlitなどのツールを使用すると、パッケージの依存関係を素敵なTOML形式で指定できます（setup.pyの要件文字列の代わりに）。 Pipfileではなくpyproject.tomlで指定するだけです。

@uranusjrあなたが言っていることは、Pipfileは、SetuptoolsやFlitなどのパッケージツール（setup.pyまたはpyproject.tomlを介して）によってまだキャプチャされていない場合にのみ、プロジェクトの依存関係を明示的にリストする必要があるということのように聞こえます

たとえば、setup.pyが次のようになっている場合：

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

その場合、Pipfileには次のものだけが必要です。

[[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}

pipenv installを実行すると、本番用に依存関係Aがインストールされ、 pipenv install --devを実行すると、開発用に依存関係AとBがインストールされます。

誰かがすでにSetuptoolsまたはFlitを使用している場合、依存関係を[packages]または[dev-packages]の下のPipfileに追加する必要がある理由はありますか？ 例としてリクエストを見ると、開発の依存関係がPipfileの[dev-packages]の下に明示的にリストされている理由はわかりませんが、 install_requiresとtest_requirementsの依存関係はすべてセットアップでキャプチャされます.py。

Pipfileに依存関係を明示的に追加する必要がある唯一の理由は、SetuptoolsまたはFlitを使用していない場合のようです。 これは正しいです？ これが当てはまらない理由はありますか？

個人的な好みだと思います。 extras_require[dev]に開発者の依存関係をリストすることは、単なる慣例です。 dev-packages OTHOは明確に定義されたキーです。 extras_require[dev]を使用すると、すべてのユーザーがpip install package[dev]を使用できるようになりますが、これはメンテナが気に入らない場合があります。 どちらか一方を好む人が理解できます。

packagesに関しては、いいえ、 install_requires IMOよりも理にかなっているシナリオは実際にはありません。 しかし、人々は創造的な使用法を思い付くと確信しています。

なぜこの問題は解決されたのですか？

@JulienPalardいくつかの理由で閉鎖されました：

1. Pipfilesとsetup.pyファイルは、実際には同期を保つことを意図したものではありません。それ自体、詳細について説明するリンクされた記事がたくさんあると思いますが、tl; dr Pipfileはほぼ同等です。トップレベルrequirements.txt
2. プロジェクト（現在のディレクトリなど）でsetup.pyをマネージドvirtualenvに解決する場合、ワークフローはpipenv install -e .になります。これにより、 Pipfileに単一のエントリが配置されます。 install_requires $を含むPipfile.lockに入れます。 install_requiresが変更されたためにvirtualenvを最新のコンテンツで更新する場合は、最新バージョンのpipenv lock && pipenv syncと同じpipenv updateを実行する必要があります。

これがお役に立てば幸いです。

実際、それらはPipfileよりも類似していますrequirements.txtに類似しています： requirements.txtはすべてのパッケージをフラットに指定しますが、 Pipfile ＆ setup.pyエントリレベルの依存関係のみが必要です。 Pipfile.lockとrequirements.txtには同様の情報が含まれています。

さらに実装できるPOC同期スクリプトを作成しましたが、現在は次のユースケースをカバーしています。
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddanは基本的に私が言っていることです。これらはそれぞれ、依存関係のトップレベルのリストを表していますが、1つは_アプリケーションのインストール_（ setup.py ）用で、もう1つは_アプリケーションの開発_（ Pipfile ）。

setup.py requirements.txt場合と同じように、オープンエンドまたは完全に固定された依存関係を宣言するオプションがありますが、ほとんどの人はここでオープンエンドの依存関係の固定を使用します。 Pipfileでは、厳密なピンまたは緩いピンを指定することもできますが、依存関係グラフの_unflattened_リストとしてこれを保持することも同様に推奨されます。 繰り返しになりますが、これらの両方がrequirements.txtファイルでも完全に有効であることを強調したいと思います。そのため、アプリケーションとライブラリの間の責任の分離を継続的に強調しています。 これは、すべてのトークとすべてのチュートリアル、およびPyPAによって出力されるすべてのメッセージングで強調されているのがわかります。

Pipfile.lockとrequirements.txtは同じものではありません。 Pipfile.lock requirements.txtを生成できますが、中間のPipfileを使用せずに、requirementsfileから直接ロックファイルを生成することはできません。 これは、 Pipfile.lockが推移閉包を表し、依存関係の解決を実行するために常に中間のPipfileが必要になるためです。

元の質問に関しては、問題のディレクトリを編集可能なパスとして含める以外に、 setup.pyファイルをPipfileと同期させる理由はありません。 pipenv lockを実行すると、 setup.pyファイルの依存関係が自動的に解決されます。 特定のユースケース、 @ iddan 、またはセットアップファイルに書き戻すために特別なパーサーが必要な理由についてはわかりませんが、setup.pyと要件に関するDonaldStufftの記事を読むことをお勧めします。 txtを使用するか、メンテナの1人がこのコメントを参照して、区別と、それがPipenvに具体的にどのように適用されるかについて説明します。

私のユースケースは、K Healthに、スタンドアロンサービスであり、パッケージとして使用できる内部パッケージを含むリポジトリがあることです。 そのため、パッケージコンシューマーとサービスのdev / deployment構成の間でトップレベルの依存関係を共有したいと思います。 Pipenvを使用して依存関係を管理しているので、 Pipfile setup.py ＃$として取得すると便利です。

＃2148のバリアントのように聞こえます（requirements.txtをPipfileに置き換えます）。

しかし、これはsetup.pyに関するものです

この。 問題。 したほうがいい。 いいえ。 なれ。 閉まっている。

この問題は、次の理由でクローズされました。

1. Pipenvはパッケージツールではありません。
2. Pipenvにパッケージ機能を含めないことが決定されました。
3. Pipenvを使用して、パッケージの開発中に開発の依存関係を管理する方法が明確になりました。
4. Pipfileはオープンスタンダードです。 Pipfile形式に基づいたパッケージツールを簡単に作成できます。 Pipenvがそれを行わないと決定したという事実は、そうすることからあなた自身を排除することを意図していません。

本当に気になる方は、自分で道具を作ってください。 この問題には多くの期待が寄せられているため、ここにソリューションを投稿すれば、牽引力を得るのは難しくないと思います。 そして牽引力で、PyPAはPipenvのように、パッケージガイドでそれを推奨することができます。 ただし、最初に実際にツールを作成する必要があります。

また、プロジェクトのメンテナに敬意を持って取り組むことを学んでください。 参考のために行動規範を参照してください。 私たちは生産的な議論をすることができてうれしいですが、私たちはボランティアであり、単に個人の希望に従うためにここにいるわけではありません。 それを管理できない場合は、わざわざ投稿しないでください。

これ以上の議論を防ぐために、この問題をロックすることをお勧めします。 明確に指摘されていると思います。

一つのことをして、それをうまくやってください！

皆さんこんにちは、

@Korijn私は、extra_requiresを使用してsetup.pyをPipfileと同期する方法を説明している部分を読みました。

私はそれを行おうとしていて、Pipfile.lockのdevセクションにextra_requireパッケージがないことに気付きました。したがって、空のvenvにソースコードがあり、 pipenv install --devを実行すると、Pipfile.lockにはextra_require要件がないためです。 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"
        }
    }
}

Pipfile.lockがextra_requiredevパッケージを追跡した正しい動作ではないでしょうか？

はい、これは私にはバグ/制限のように見えます。 これについては、別のバグ/問題を提出する必要があります。

現時点では特定できませんが、この問題についてトラッカーで問題が発生していると思います。 開く前に、既存の問題を検索してください。 前もって感謝します ：）

これはバグではありません。pipfileで同じベースエントリを複数回使用することはできません。 devセクションとデフォルトセクションで依存関係を指定すると、何があってもデフォルトセクションが優先されます。

私は通常の思考実験をウォークスルーしますが、今は時間がないので、何かをデプロイして開発依存関係が競合を隠していることがわかったときに、依存関係の競合や驚きを引き起こす可能性があると言ってください。

@techalchemyでは、この場合、開発者の依存関係をどのように管理できますか？ pipenvの良い使い方を知りたいだけです

私は自分のプロジェクトでこれについて考えていましたが、 packages / dev-packagesの区別は本当に必要ないことに気づきました。 packagesに{editable = true, extras = ["dev"], path = "."}をリストするのはどうですか。

このpipenv-setupパッケージをチェックしてください

pipfile / lockfileを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

$ pipenv-setup sync --devを実行して、開発の依存関係を追加の要件に同期できます。 または$ pipenv-setup sync --pipfileで、代わりにpipfileを同期します

および$ pipenv-setup checkは、チェックのみを行います

それらすべてを解決するための1つのコマンド💯

pipenv-setupパッケージをpipenvにマージする計画はありますか？

@peterdeme

pipenv-setupパッケージをpipenvにマージする計画はありますか？

@uranusjr @techalchemy上記の議論に基づいて、pipenvは多少異なる哲学を持っているかもしれないと思います。 しかし、メンテナが同意する場合は、プルリクエストを送信して、 pipenv-setupを統合してみてください。

組み込みのjsonモジュールを使用して、いつでもPipfile.lockを解析できます。 setup.py install_requiresのnon-dev依存関係を抽出します。
"default"キーには、パッケージ名のネストされた「dict」と、 versionの数字およびmarkersが含まれています。
外部からのインポートに依存する必要はありません。

@ Kilo59私は人々がこれをしているのを見ました。 言及するヒントは、setup.pyにdata_fileとしてPipfile.lockを含めることを忘れないでください（またはMANIFEST.inに含めることを忘れないでください）。 これは、依存関係が固定されたロックファイル用です。 一方、Pipfileでセマンティックバージョニングが必要な場合、pipfileの解析は簡単ではありません。 同じ依存関係の要件が複数の形式で表示される場合があります。

ありがとう@Madoshakalakaあなたのツールはうまく機能します！

Setup.pyの依存関係がPipfileのプロジェクトの依存関係とは異なることについて、他のピアに同意します。 しかし、それでも、手作業なしでそれらを同期するプログラム可能な方法を持つことは、時間を節約する大きな機能です。 また、タイプミス/一般的なエラーを回避します。

黒くなったsetup.pyもいい感じでした：+1：