同意しました。 依存関係リンクのpipの現在の動作は、本当にひどいものです。

4295

3610

[＃3939に書き込み、コメントをここに移動]

したがって、主な問題は次のとおりです。 requirements.txtファイルを使用したくない場合（たとえば、すべてsetup.cfg指定された宣言型の依存関係が必要なため）、どのように指定する必要がありますか依存関係としてのURL？

これは機能しません：

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

また、依存関係のリンクは奇妙で削除しても問題ないと思いますが、標準的に、これらのユースケースがない場合、このユースケースはどのように提供されますか？

もう1つの問題は、 dependency_linksをsetup.cfgで指定できず、setup.py引数としてのみ指定できることです。 それらが非推奨にならない場合は、修正する必要があります。

これに関するニュースはありますか？ 進行中の代替手段はありますか？ 依存関係_links_は、ライブラリの内部/プライベート配布の唯一のオプションのようです。

非推奨にするのではなく、修正する必要があります。多くの人は、ライブラリの名前バージョンをinstall_requiresに配置することと、tarbalとeggを含む依存関係リンクの両方を忘れているため、忘れたり混乱したりします。 別の方法として、 @ jleclancheが、install_requires内のtarballへの簡単なリンク（卵を指定することはオプションである可能性があります）を提案していることを確認したいと

私たちは一人ではないと思います： https ：

devpiのような

@dstufft btw-devpiの存在は、依存関係リンクを不要にする問題に対するよりクリーンな解決策を示していると主張したいと思います

IMHOインデックスの継承+ホワイトリスト/ブラックリストは、運用レベルでより一貫性があり、より理解しやすいものです

@RonnyPfannschmidt 、提案に感謝します。私は重要な何かを見逃しているようです（この非推奨についての議論は長すぎます）が、一般的に言えば、 redditからのこのコメントにこれ以上同意することはできません：

devpiは解決策になる可能性がありますが、メンテナンスが必要な別のサービスをゲームに導入し、管理者がセットアップするのを待たなければならないので、すぐに作業を開始することはできません。 また、パッケージをビルドしてからdevipに配置する必要があります（またはdevpiにgitリポジトリを追跡する機能がありますか??）

理想的には、ライブラリにファイルを追加するか、setup.pyに数行追加するだけの代替手段が必要です。

私は基本的にそれを削除するという根本的な決定を理解していません、それがどのように悪い慣行や不安につながる可能性があるかはわかりますが、それが内部使用のために保持されている限り、それは大きな問題ではないはずです。

4175は、PEP 508URLサポートがpip10にあることを意味します。これは閉じることができると思います。

@pfmoore @dstufftを考えますか？

https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285dは、 @構文を依存関係に使用できないことを意味していると思ったので、これは＃4175がこの問題の解決策ではないことを意味します。 そこにあるコメントは、PyPIがそれを使用するアップロードをブロックできるようになるまで依存関係の@サポートを実装すべきではないというものでした（PyPIから何かをインストールして任意のURLから何かを取得できるようにしたくないため） 、おそらく）。

代替手段、つまりPEP 508サポートが導入されるまで、非推奨にしないでください。 それまでは、あまりにも多くの人が使っています。

このための適切なワークフローは何ですか？

機能を追加する必要のあるライブラリがあるとしましょう。 Githubでフォークします。 機能はすぐにマージされる予定はないので、PyPiの代わりにGithubフォークを使用するように設定したツールがあります。

これで、pipを使用してツールをインストールするときに、すべてのユーザーが--process-dependency-linksを追加する必要があります。これは非推奨であり、一度削除されたフラグです。

setup.pyに欠落しているオプションがありますか、それともこれを回避する方法が本当にありませんか？ これを行う唯一の実行可能な方法は、フォークされたpypiパッケージをプッシュすることであるように思われます。 とにかく、プルリクエストがマージされると、それはユーザーの混乱を増すだけです。

これに来てみましょう。

--process-dependency-linksは、今日、実際には代替手段がありません。 したがって、先に進んで非推奨にすることをお勧めします。

ただし、フラグは、pipが任意のURLに到達することを意味します。これについては、警告が添付されている必要があります。

@pradyunsg永久にそれを殺す実際の計画がない限り、私はそのゾンビを休ませるか、取り除くことを強くお勧めします

ピップが「いいえ、私はあなたの借金を引き受けません」と言わない限り、私は実際にそれを必要とする人々が状況を修正するインセンティブを持っているとは思わない

ピップメンテナーとしての私の懸念は、ピップがエクスプロイトのベクトルになることを許可しないことです。 PipはデフォルトのインデックスとしてPyPIを想定しているため、PyPIには暗黙の信頼があります。 だから私の最初の質問は：

1. dependency_linksメタデータを持つパッケージがPyPIに存在しますか？
2. dependency_linksのプロジェクトのアップロードを拒否するようにPyPIを変更できますか（またはすでにそうしていますか）？
3. あるいは、pipは、PyPIからダウンロードされたパッケージの依存関係リンク（オプションが設定されているかどうかに関係なく）の処理を単に拒否できますか？

悪意のあるdependency_linksを含むPyPIのパッケージにpipユーザーが噛まれる方法がないと確信できれば、それほど心配する必要はありません。 カスタムインデックスの使用を選択したユーザーは、それを信頼するかどうかを自分で決定する必要があります。 （それでもフラグを保持したいのですが、これは潜在的にリモートエクスプロイトであり、常に明示的にオプトインする必要

したがって、次の変更があります。

1. PipはPyPIからの依存関係リンクを処理しません（明示的に、またはそれらが存在しないことがわかっているという理由だけで）
2. --process-dependency-linksフラグは非推奨ではありませんが、カスタムインデックスに対してのみ機能します。

それを現状として受け入れても大丈夫です。 依存関係リンクスタイルの機能が必要な人は、（もしあったとしても）どのように前進したいかを自分たちの間でぶち壊すことができます。

誰かが望むなら、依存関係リンクのメタデータを定義する標準にそれらすべてを入れることができ、現在の非推奨は「標準で指定された動作を優先して現在の動作が削除される」になります。 しかし、ピップ中心の観点からは、私はむしろそれを行いたいと思います-依存関係のリンクを必要とする人々に標準化の作業を任せます（結局のところ、彼らはルートを持っているので、それは彼らの利益になります-標準的な変更を取得します-完全なコミュニティコンセンサスでpipの動作を変更する）。

基本的に、依存関係リンクを置き換えることを目的とした機能がありますが、それを使用するPyPIへのアップロードをブロックする方法がまだないため、pipはまだそれを尊重し始めていません。

＃4175のことですか？ 86b0779のためにブロックされているのはどれですか？ たぶん、 https：//github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167を変更して、 comes_fromがPyPIの場合にのみエラーを出すことができますか？

次に、 --process-dependency-linksの非推奨警告を変更して、ユーザーが@構文に切り替え、妥当な非推奨期間の後に--process-dependency-linksを削除する必要があることを示すことができます（開始する必要があります） @構文が使用可能になった時点からのクロック刻み）。

@pfmooreええ、それはまさにそれであり、それは前進の可能性のある道のようです。

わかった。 誰も最初にそれに到達しない場合、私はPRを書くことについて見るでしょう。

私が収集したものから、ここでのユーザーの問題は、代替手段がない機能のためにそれを渡すときに、「ねえ、私は非推奨です」と明示的に言うオプションを渡す必要があるということです。

非推奨期間中、dependency_linksのサポートを完全に廃止することに賛成です。 それまでの間、PEP 508 URL依存関係のサポートを追加します。これは、pipを使用するときはまだ大音量であり、オプトインである必要があると思います。

つまり、次のことを意味します。

• PEP 508url-depsを処理する機能をフラグの後ろに置きます
  
  
  
  • 余談ですが、セキュリティに関係するユーザーがドキュメントを確認できるようにフラグに名前を付ける必要があります
  
  
• PyPIパッケージからのPEP508 url-depsのインストールを拒否し始める
• 依存関係-リンクは非推奨のままですが、削除する日付があります
  
  
  
  • 正直なところ、私はこれを、代替案を印刷する単一のリリースよりも長い非推奨期間にしたくありません。
  
  

私は昨日それをタイプしましたが、それを送りませんでした。 @pfmooreの最後のコメントと基本的に同じだと

_わーい！

URL部門はオプトインフラグを必要としますか？ PEP 508はそうは言っておらず、現在の実装はそうしていません。 論理はわかりますが、セキュリティと使いやすさの質問についての私の判断は信用できません。

また、切り替えを開始する前に、プロジェクトが依存関係リンクから@構文に切り替える方法に関する明確なドキュメントを確認したいと思います。 非推奨の影響を受ける人々に連絡することはすでに十分に困難であり、対処方法を理解できないという警告は役に立ちません。 理想的には、警告には「切り替え方法」ドキュメントであるIMOへのポインタが含まれている必要があります。

セキュリティと使いやすさの質問についての私の判断を信用していません。

私は「デフォルトで安全である」という傾向があり、安全性の低い動作をオプトインします。

スイッチのプッシュを開始する前に、プロジェクトが依存関係リンクから@構文に切り替える方法に関する明確なドキュメント

私にはいいですね。

私は「デフォルトで安全である」という傾向があり、安全性の低い動作をオプトインします。

私の仕事でファイアウォールとセキュリティの制約に対処するのに苦労している人として、私たちはこの機能が最も役立つと思われる環境の種類（内部開発、クローズドソース）についてあまり理解していないことをよく知っています、厳密に制御されたワークフローやネットワークレイアウトなど）。 したがって、私の傾向は、デフォルトのワークフロー（PyPI）に対して安全であるが、ワークフローにとって明らかに重要であるが、彼らがしなければならないトレードオフを適切に理解していないユースケースを持つ人々の邪魔になるような追加の障害を置かないことです。作る。

私の考えでは、「パッケージが明示的に使用することを選択したサーバーからのものである場合」は、URLリンクを許可するのに十分なオプトインです。

見る？ 私が意見を

ワークフローにとって明らかに重要であるが、彼らがしなければならないトレードオフを適切に理解していないユースケースを持つ人々の邪魔になるような追加の障害を置かないでください。

けっこうだ。 一部のユーザーがワークフローへの洞察を提供できれば、それは素晴らしいことです。

「パッケージが明示的に使用することを選択したサーバーからのものである場合」は、URLリンクを許可するのに十分なオプトインです。

ここはよくわかりません。 ：/

見る？ 意見がないわけではなく、自分の偏見が表れていないかどうかわからないだけです😄

ヘヘ。

けっこうだ。 一部のユーザーがワークフローへの洞察を提供できれば、それは素晴らしいことです。

私の考えでは、「パッケージが明示的に使用することを選択したサーバーからのものである場合」は、URLリンクを許可するのに十分なオプトインです。

GitHubからのソースを許可するだけで、問題の99％が解決します。 アップストリームパッケージにはバグまたは不足している機能があります。 私はそれらをフォークして修正し、PRを発行してから、それらがマージされてPyPIでリリースされるまで、おそらく非常に長い時間待ちます。 それまでの間、私のパッケージはそれらのパッケージの修正に依存しています。

これは、1行で実行できる限り、オプトインできます。

直接リンク（HTTPSなどを想定）を使用することは実際にはセキュリティの問題ではなく、単なる可用性の問題です。 PyPIからのそれらを禁止しているので、それで十分であり、別のフラグは必要ありません。

私の仕事では、 @ pfmooreが言及したいくつかのユースケース、つまり、パッケージがオープンソース、クローズドソースになる前の内部開発などに該当します（常に内部パッケージは他の内部パッケージに依存し、それらはすべてバージョン管理サーバーにあります） ）。
ただし、ファイルシステムの場所を参照している人の使用例もあります...
ホワイトリストに登録されたホスト/場所のリストを提供することは理にかなっていますか？ フラグの名前は、 @ pradyunsgが示唆しているように、IMOが、関連するリスクをユーザーに認識させるのに十分な説明的である必要があります。 多分--whitelisted-host ？

@masdeseiscaracteres誤解されているかもしれません-パッケージがPyPIから取得された場合、その依存関係のいずれかが@参照を介して指定された場合、失敗することを示唆していました。 しかし、とにかくPyPIでそのようなケースが発生することはないはずです（ある時点でそれらを拒否することを期待していますが、まだ設定できていません）。 @参照の他のすべての使用はOKです。

私たちが@pfmooreによって記述されているものないPRを進めるつもりだように見えますhttps://github.com/pypa/pip/issues/4187#issuecomment -389846189。

PRは大歓迎です。 :)

私はこれに到達する時間がなかったことに注意してください-変更が難しいためではなく（前述のように、それは単にcomes_fromに対するチェックであるように見えます）、むしろ私が挑発する方法がわからないためです自分でエラーを起こします（さらに重要なのは、そうするテストの書き方がわかりません）。 誰かがそのようなテストケースの例を提供できれば、それは非常に役に立ちます。

誰かがそのようなテストケースの例を提供できれば、それは非常に役に立ちます。

これを実証する既存のテストtest_install_pep508_with_url_in_install_requiresがあります。

PyPIからインストールする際のエラーについては、URL要件のあるものをPyPIに実際にアップロードするよりも良いオプションはありません。 😞この目的のためにPyPIにパッケージをアップロードしました。 https://pypi.org/project/pep-508-url-deps/

もう1つは、 comes_fromはURLまたはパスではなく、 'box==0.1.0 from file:///private/tmp/box'行に沿った文字列です。 この問題を修正しようとしている人は誰でも、パッケージの出所に関する情報を入手できるように、エラーを発生させるためのより良い方法を見つけ出す必要があります。 :)

@pfmooreこの問題は私の心の近くにあります😄@ pradyunsgのアップロードはあなたに必要なものを提供しますか、そしてあなたはまだこれに取り組むことを計画していますか？ そうでなければ、私はそれでスイングすることができます。

@bstrdsmkrいいえ、 @ pradyunsgが言うように、 comes_fromはソースURLではないため、思ったほど単純ではありません。 ですから、いつ時間があるかわかりません（私はこの機能を個人的に使用していないので、優先順位リストの上位にはありません）。

上記のように、PRは歓迎します:-)

アップロードされたパッケージは実装にはまったく役立ちません。機能のテストにのみ役立ちます。

私の理解では、必要な修正は次のようなものです。

if req.url and is_like(req.url, PYPI.url):
    raise

https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172で
ここで、URLが同じドメインにある場合、 is_like()はTrue返します。 あれは正しいですか？

うん。 そう思います。 それがコードの変更になります。

また、テストとNEWSエントリを追加/更新する必要があります。

また、この変更は、ドキュメントへのリンクを提供する非推奨メッセージと、代替手段に切り替える方法をユーザーガイドに示す追加セクションを保証するのに十分重要だと思います。

ピップメンテナーとしての私の懸念は、ピップがエクスプロイトのベクトルになることを許可しないことです。 PipはデフォルトのインデックスとしてPyPIを想定しているため、PyPIには暗黙の信頼があります。

いいえ、明確な信頼があります。 また、依存関係で外部ソースを使用しないようにするためのセーフガードを追加しても、状況は改善されません。公開されているVCSよりもpypiでマルウェアを隠す方が便利です。

IMHOのより良いアプローチは、開発者のVCSをプライマリソースとして使用し、pypyをそれらを指すレジストリとして保持し、VCSのコンテンツがpypyから取得したものと同一であることを示す強力な暗号化証明を備えたキャッシングプロキシを保持することです。 つまり

0登録

dev -- public key --> pypa

1アップロード

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2アイドル：

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2取得

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1シグニチャにより、インストールされたソースはVCSのソースと一致します
2作者も一致します
3 pypaは新しいユーザーと不正行為を行うことができますが、古いユーザーは不正行為を検出する可能性があります
4作成者は、pypyに与えられた以外のWebインターフェイスブランチに表示してチートし、pypyに別のブランチを送信できます。 ブランチをURIの必須部分にすると、うまく機能しません。

@KOLANICH pypy / pypaとは、PyPI（Python Packaging Index）のことだと思います。 PyPyはPythonの代替実装です。 PyPA（Python Packaging Authority）は、PythonPackagingスペースで主要なプロジェクトを維持しているボランティアのグループです。 頭字語を正しく取得するか、使用を控えてください。

あなたは、既存の十分に確立されたサービスの設計を根本的に変更することを提案しています。 このような大きな変更を希望する場合は、アーキテクチャを管理/変更して既存のワークフローの移行/中断を最小限に抑えるために、少なくとも（実行可能な）移行計画とPOC実装を提供することを歓迎します。 外部ホスティングに依存することは、過去にPEP 470でPyPIから明示的に削除されたものですが、それはあなたが提案しているものとはかなり異なるケースであることに注意してください。

PyPIはボランティアによって維持され、寄付/後援されたインフラストラクチャで実行されます。 あなたはそれが別のボランティアが維持/運営しているサービスであるTorを介して接続することを提案しています。 これらは両方とも主要なプロジェクトであり、ユーザーが直接負担したり、ユーザーに表示したりすることはありませんが、実行を維持するためのコストがかかります。

それでもなお、これはこの議論にふさわしい場所ではありません。 PyPIの再設計を提案したい場合は、 https：//github.com/pypa/warehouseでディスカッションをやり直すことをお勧めし

提案ありがとうございます。

これが後のリリースにプッシュされた理由については、＃5571-これに関するPRを参照してください。

PIPインストールログの警告はこのURLを示しますが、ここでも他のチケットでも問題の解決策はありません。

さらに、これはさらに混乱を招きます。PyPIとはどういう意味ですか？ PyPIインターフェース（Artifactoryなど）、具体的にはpypi.orgを実装するサーバーを意味しますか？

さて、明らかに、 setuptools （別名setup.py install ）とpip install両方を使用したパッケージのインストールをサポートしたい人は、ピクルスになります。 この状況で誰かが複数の相互依存パッケージを処理する唯一の方法は

さて、私が間違っている場合は訂正してください。しかし、これまでのところ、PyPAがサーバーへのアップロードに関して行った決定に基づいてこれを取り除けば、基本的に、Artifactoryユーザーにとってpip役に立たなくなります。相互に依存するパッケージを持つプライベートリポジトリを持っている会社。

私が間違っていて、この全体の話の中で何かを逃したことを教えてください（私はしばらくそれをオンとオフでフォローしていました）。 私はPEP508を赤くしましたが、この点では実際には違いはありません。少なくとも、それがどのように状況を改善または悪化させるかはわかりません。

@ wvxvw-traiana PR＃5571を逃したと思います
そのPRの前（および現在のリリースでは-18.0）、pipはPEP508構文で指定された依存関係のインストールを拒否します。

その後、PR（すでにマージされているので18.1以降にあるはずです）pipは、それらに依存するパッケージがpypi.orgからのものである場合にのみ、そのような依存関係を拒否します。

pypiからのものに依存するプライベートリポジトリからパッケージをインストールする場合、明らかにそれは問題ありません。
プライベートリポジトリからのものに依存するpypi.orgからパッケージをインストールすると、失敗します。
プライベートリポジトリ内のものに依存するパッケージをプライベートリポジトリからインストールする場合、それは問題ありません。

それが物事を片付けるのに役立つことを願っています

@bstrdsmkrそれは同じ起源ですか、それともpypiは特別な場合ですか？ つまり

別のプライベートリポジトリからのものに依存するプライベートリポジトリからパッケージをインストールする場合。

この背後にある理由についてさらにコンテキストを追加するには：

1. 直接URLリンクを使用すると、パッケージはインターネット上のどこからでも任意のコードのダウンロードと実行をトリガーできます。 あなたがそれを行うパッケージに責任を負っているならそれはOKです、それで私たちはその理解に直接URLリンクを許可します。
2. 人々はPyPI（具体的にはPyPIであり、一般的なパッケージインデックスではない）からインストールし、そこからダウンロードしたパッケージを信頼することを期待しています。 多数のPythonユーザーを公開するPyPIパッケージの侵害を防ぐために、PyPIからのパッケージが直接URLリンクに依存することを許可していません（ユーザーに負担がかかりすぎて、すべてを監査する必要があると主張するためです）外部コードへのリンクに使用するPyPIから）。
3. 依存関係リンクはsetuptools固有のメカニズムであり、pipではなくsetuptoolsの内部機構によって処理されます。 だから、直接URLリンクとは異なり、我々は、彼らが何をすべきかを制御することはできません。 そのため、私たちは自分たちで処理する標準の直接URL形式を採用してそれらを非推奨にしました。

setuptools（別名setup.py installの実行）とpip installの両方を使用したパッケージのインストールをサポートしたい人は、今やピクルスになります。

trueの場合、これはsetuptoolsが合意された標準である直接URLリンクのサポートを実装していないためです。 彼らと一緒にそれを自由に上げてください。

別のプライベートリポジトリからのものに依存するプライベートリポジトリからパッケージをインストールする場合。

それはうまくいきます。 PyPIは関与していません。

OK、それで、一方で、これが私に影響を与えないことを嬉しく思います。

一方、この「修正」は、どうやってそれを置くのか...回避するのは簡単すぎるようです。

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

私のビジネスではありませんが、実際には表面レベルのアプローチのようです。 （他の攻撃ベクトルは他のコメントで言及されており、setup.pyで好きなものを簡単にダウンロードできます）。

ユーザーがユーザーが回避するのが難しいようには設計されていません。 これは、PyPIには、URLに直接依存するパッケージのアップロードをブロックする方法がまだないという事実に対する（限定的な）ソリューションを提供する手段です。 コンテキストについては、 https： //github.com/pypa/pip/pull/4175#issuecomment-266305694を参照して

@ dpwrussellpypi.orgは特殊なケースです。 プライベートリポジトリからプライベートリポジトリへの変更後は、正常に機能します。

@ wvxvw-traianaそれはあなたが自分でそれをするのを妨げることを意味するものではありません。 これは、pypi.orgからパッケージをインストールしているだけだと思ったときに、他の誰かがあなたにそれをしないようにすることを目的としています。

現在の議論とは関係なく、この非推奨の警告を実際に更新していないため、これを再開します。

5726は、PEP 508 URLの使用を提案する言語を追加します。これは、IMOがこれに必要な最後のビットです。

じゃあ。 要約させてください：

• 依存関係リンクはまだ非推奨であり、pip19.0で削除されるようにスケジュールされています。
• それの標準的な裏付けのある代替品は、PEP 508URLの依存関係です。
• PyPIからインストールするときに、パッケージにPEP 508 URL依存関係がある場合、pipはインストールを中止します。

@pfmooreは、これらの決定の理由をここで詳しくhttps ：

@pradyunsg setup.pyのinstall_requiresでPEP 508 URL依存関係が許可されるのはいつですか？ 日付は設定されていますか？

pipの次のリリースでは、10月に予定されている18.1です。 pipの3か月のリリースサイクルの詳細については、https：//pip.pypa.io/en/latest/development/release-process/を参照してください。 :)

https://github.com/pypa/wheel/issues/249は、PEP 508のURL依存関係が実行可能な代替手段になる前に、対処する必要があります。

PEP 508のURL依存関係が実行可能な代替手段になる前に、 pypa / Wheel＃249に対処する必要があります。

これは解決されました。

pip 18.1リリースノートには、

PEP 508URL要件を依存関係として使用できるようにします。

セキュリティ対策として、PyPIからパッケージをインストールするときに、それらのパッケージがPyPIでホストされていないパッケージに依存している場合、pipは例外を発生させます。 将来的には、PyPIはそのような外部URL依存関係を持つパッケージの直接アップロードをブロックします。 （＃4187）

つまり、これは基本的にURLを使用して依存関係を指定できることを意味しますが、それらがPyPI URLでない場合、パッケージはpipを使用してインストールできませんか？ たぶん私はそれを完全に間違っていますが、URLの依存関係はどのように使用されることになっていますか？

PyPIでホストされている@JarnoRFBパッケージは、URLに依存することはできません。

PyPIでホストされていないパッケージは、URLに依存する可能性があります。 パッケージをgithubから直接インストールする場合（たとえば）、URLの依存関係が解決されてインストールされます。 そのようなインストールの例：

pip install git+https://github.com/bstrdsmkr/some_package.git

基本的に、URLからインストールする場合は、URLに依存する可能性があり、そうでない場合は依存しません。 また、わかりやすくするために、URLと非URLの両方の依存関係を持つこともできます

マイナーな追加：

... URLからインストールする場合、URLに依存する可能性があります

... URL（VCSなど）、ローカルファイル、またはPyPIではないパッケージインデックスからインストールする場合は、...

それで、上記の説明に従ってinstall_requiresを処理するpipのバージョンはありますか？ 最終状態の上のタグを理解することはできません。現在のpipドキュメントは、setuptoolsのinstall_requiresドキュメントを指しており、それでもdependency_linksを使用するように指示されています。

自分でドキュメントに話すことはできませんが、PyPI以外のパッケージがURLから依存関係をインストールできるようにするこの「緩和」はpip18.0でリリースされました

AFAIK、install_requiresのURL依存関係は、pip18.1以降でサポートされています。

PEP 508URL要件を依存関係として使用できるようにします。

出典：リリースノート

うーん、私の側のタイプミス-

--process-dependency-linksを使わずに何をすべきかについて（私のように）この問題に最初に遭遇した人々のために、小さいながらも成功した例をここに残したいと思います。 このワークフローを使用して、ユーザーはGitHubまたはローカルソース（PyPIではない）からpipインストールを実行したり、pipインストールrequirements.txtまたはpython setup.pyインストールを実行したり、pipを使用してTravis-CIで作業したりできるようになりました。バージョン18以降なので、多くのベースをカバーしていると思います。 私はそれが誰かに役立つことを願っています、そしてこれが他の人にとって話題から外れているように思われるならば私の謝罪：

あなたのrequirements.txtファイルで、人々がパッケージ「foo」のGitHubdevブランチに依存できるようにしたいと仮定します。例：

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

setup.pyファイル：

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

install_requiresとrequirements.txtを混同するのは賢明ではないと言う人もいます。リリースされたバージョンについては同意しますが、これは開発にはうまくいくと思います。

ああ、きちんと。 したがって、パッケージ「A」と「B」の両方がこのメソッドを使用し、パッケージ「A」が依存関係として「B」をリストしている場合、「A」をインストールすると、実際には「B」のrequirements.txtが処理されます。 （通常はそうではありません）-そうですか？

また、今朝、install_requires自体が少し悪いことを読みました。これらのインストールはsetuptoolsによって行われたため、pipオプションは無視されましたが、その情報が古くなっているかどうかはわかりません...

また、今朝、install_requires自体が少し悪いことを読みました。これらのインストールはsetuptoolsによって行われたため、pipオプションは無視されましたが、その情報が古くなっているかどうかはわかりません...

install_requiresとsetup_requires混同しています。

ああ、きちんと。 したがって、パッケージ「A」と「B」の両方がこのメソッドを使用し、パッケージ「A」が依存関係として「B」をリストしている場合、「A」をインストールすると、実際には「B」のrequirements.txtが処理されます。 （通常はそうではありません）-そうですか？

@stevebrasierはい、そうなると思います。これは、Bとは異なるバージョンの必要なパッケージをAに固定した場合に問題になる可能性があります。

こんにちは皆さん、この場合の非推奨の経路は短すぎたことに注意したいと思います。 依存関係リンクはかなり前から非推奨としてマークされていることは知っていますが、それらを置き換えるために使用できるPEP 508 URLは、18.1まで実装されていません。 その結果、依存関係リンクからURL要件に切り替えるまでの期間はわずか3か月でした。これは、大規模なプロジェクトでは非常に短い時間です。

@rgerkinこんにちは、私は無駄にあなたの指示に従おうとしています、

PACKAGE @ git + ssh：//[email protected] ：OWNER / PACKAGEを検索していgit @ BRANCH
https://pypi.org/simple/PACKAGE/を読む
'PACKAGE'のインデックスページが見つかりませんでした（スペルが間違っている可能性がありますか？）
すべてのパッケージのスキャンインデックス（これには時間がかかる場合があります）
https://pypi.org/simple/を読む

PACKAGE @ git + ssh：//[email protected] ：OWNER / PACKAGE。 git @ BRANCH 、これはinstall_requiresにあります。

なぜ私が上記を取得しているのか分かりますか？

@KevinMars私の例とあなたが持っているものとの間には、git_ssh、bitbucket、a.gitサフィックス、名前付きブランチの使用、バージョンタグなしなど、いくつかの違いがあります。 たぶん、それらの1つ以上が、あなたのURLではなくPyPIで検索するようにpipを導いています。 どのバージョンのpipを使用していますか？

発言に私が見つけたことを何か：使用するsetup.pyでパッケージをインストールするためにpython setup.py installまだ中に外部依存関係の宣言を必要とdependency_links 。

setup.pyファイル：

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkinこのソリューションを共有していただきありがとうございます。 しかし、Pythonパッケージをセットアップするためにpbrを使用している場合はどうなりますか？ これをpbrに合わせる方法は？

@KevinMars私はまったく同じ問題を抱えています。 修正を理解したことがありますか？ SSH経由でプライベートビットバケットリポジトリの特定のブランチを要求しようとしています。

--process-dependency-linksがもう存在しないことに気づきました。 コミュニティのすべての仕事に感謝しています。 議論を終わらせないという決定を正当化しようとし、問題の解決とリダイレクトの迷路が選択された解決策でしたが、それでもこのオプションを残しても誰にも害はなかったと思います。