うーん、PyPIで利用可能なすべてのパッケージバージョンを一覧表示するコマンドが必要な場合があります。
あなたが思うこと？

お気に入り：

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

私はその考えが好きです。

Original Comment By: CarlFK

フォークに実装したばかりです。 carljm、jezdez、ianbの意見が欲しい
マージする前に。

こちらで確認してください： https ：//bitbucket.org/hltbra/pip-list-
コマンド/チェンジセット/ e5c135a46204

Original Comment By: Hugo Lopes Tavares

私はこれについて深く考えていませんが、改善する方が良いようです
バージョンも一覧表示する「search」コマンド（-vフラグが付いたすべてのバージョンを一覧表示する場合があります）
または何か）、新しい個別のコマンドを追加するのではなく。 この機能
論理的には検索の一部のようです。

Original Comment By: Carl Meyer

他のERが実装されている限り、これを検索に追加しても問題ありません。
djangoのバージョンを探すときに（本当に）3000行も取得しないようにするためです。
（すべてのdjango-fooが原因で、「pipsearchdjango」のヒット数は1000を超えています。
パッケージ。 ）。

Original Comment By: CarlFK

インストールされるバージョンを表示する必要はないと思います
利用可能なバージョンのリストがあります。これは、どれを簡単に判別できるためです。
これらは最新です。 さらに、新しいフラグを使用する理由はありません
オーバーヘッドはゼロに近づく傾向があるため、このリストの出力を有効にします。 これは
ほんの小さな変更：
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

こんにちはカール、私は検索コマンドにオプションを追加することについて考えていますが、私の恐れ
インストールコマンドに何が起こったのか：「アップグレード」したい場合
パッケージの場合、「インストール」オプションを使用する必要があります。これは奇妙なことであり、私たちはそれを知っています。

そして、ほとんどの人が検索にオプションを追加する方が良いと思うなら、私もわかりません
search--versionsまたはsearch-vの使用に関する多くの問題。

Original Comment By: Hugo Lopes Tavares

デフォルトで利用可能なすべてのバージョンをリストするのは冗長すぎると思います。 いくつか
パッケージにはpypiで利用可能なバージョンがたくさんあります-10または20は珍しいことではありません
まったく。 デフォルトで最新バージョンとフラグ付きのすべてのバージョンを一覧表示
合理的なようです。

そして私はCarlFKに同意します。検索を行うには改善も必要です。
絞り込みやすい。 問題は、PyPIのAPIが提供するものに依存していることです。
それほど多くはありません。PyPIをすべてダウンロードして正規表現を実行するわけではありません。
ローカルで検索！ --exactフラグのようなものを検索するのが好きです
この変更の一部であるため、たとえば「--exact django」を検索して、
結果にdjango自体が含まれます。

Original Comment By: Carl Meyer

こんにちはジャンパ、xmlrpcから取得したものを使用してバージョンを表示するための素晴らしいアイデア
繋がり！

私はpipを検索して次のスニップを取得しました：

pip                       - pip installs packages.  Python packages.  An

easy_install置換（バージョン：0.2、0.2.1、0.3、0.3.1、0.4、0.5、0.5.1、
0.6、0.6.1、0.6.2、0.6.3、0.7、0.7.1、0.7.2、0.8、0.8.1、0.8.2）

これは、多くのバージョンを使用した、非常に大きなパッケージのリストになります-
私たちの検索は名前と要約を気にするからです。 私たちはそれを気にする必要がありますか？

Original Comment By: Hugo Lopes Tavares

エンドユーザーとして、私は別のリストコマンド*を持つというアイデアが好きです。 時間として
別のコマンドを実行すると、単独で変更および拡張する方が簡単な場合があります。 に
別のリストコマンドをより便利にする場合は、どのバージョンを指定できますか
いずれか、現在インストールされています。

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

注：YUM（RedHat）、pkglist（BSD）、
dpkg（Debain）は、個別のリストフラグまたはコマンドを提供します。

Original Comment By: Kelsey Hightower

カール、私はこの問題について別の日を考えていました、そして私は同意しなければなりません
ケルシー：別のコマンドは悪くありません。

そのパッケージ名だけが必要であることを示すためにフラグを使用することを考えてみてください。
使用可能なすべてのバージョンを取得することを示す別のフラグ。

少し変です。

説明してみましょう：

$ pip search -v --exact Django

対

$ pip list Django

インストールされているバージョンを表示するというKelseyのアイデアは、リストを改善するだけです
指図。

Original Comment By: Hugo Lopes Tavares

検索コマンドに変更を加えました。

検索コマンドには、インストール済みで利用可能な最新バージョンがすでに表示されているため、検索コマンドを拡張して、利用可能なすべてのバージョンも一覧表示する方が理にかなっています。

これが私のチェンジセットです： https ：//github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

これの状況はどうですか？ pipを使用してPyPIで利用可能な最新バージョンを確認できますか？

これはすでに実装されていますか？ これは約2年間私を悩ませてきました、そして私はこれが解決されるのを見たいです。
バージョンのフラグと組み合わせた限定検索は、非常に使いやすいソリューションのように見えます。

バージョンを表示する方法を検索しているときにこのスレッドに出くわしたことをここに追加したかっただけです...私はpipsearch -v packageを試しました-どういうわけかそれは私には直感的に理解できたでしょう：パッケージの詳細な説明バージョン情報を含むインストールされます...

私の同僚が私にそれについて尋ねた後、私はこの機能がまだ実装されていないことに気づきました。 今後のバージョンのpipで利用可能になる予定はありますか？

このPRは関連があると思いますが、現在取り組んでいますか？

また、 Pythonパッケージの現在の状況と将来についてのLinuxconf 2014の講演「PythonPackaging 2.0：他の人とうまくやっていく」にも興味があるかもしれません。 スピーカーは（私が正しく理解していれば）pipのメタデータの制限のいくつかは元々CPANに基づいていたPyPIの設計の結果であり、PyPIのバックエンドを作り直した（テストを使用して現在のものとの互換性を維持しながら）と述べました状況を改善する必要があります。 彼は主に「システムインテグレーター」、つまりダウンストリームパッケージャーについて話していましたが、それはこの問題のようなものに影響を及ぼし、それらを解決しやすくするだろうと思います。

+1,000,000

そして今はどうですか？

さて、インストールせずに最新バージョンを表示する方法はありますか？
この問題は2011年から公開されており、上記で見たパッチは1行だけです。 :(

これは有効にするマイナーな機能のようですが、現時点でapt-cache madisonと同等のオプションがないのはなぜですか？

検索するときにも、PyPiパッケージの最新バージョンを確認したいと思います。 完全に一致させることは機能しますが、回避策としてawkを使用します。

これも私を苛立たせ、これにはほとんどまたはまったく希望がないことを見て、私は代替案を作成することは私の時間の価値があるかもしれないと判断しました。 この問題に加えて、私は他のいくつかの要求された機能（正規表現検索や色付き出力など）を実装しました。 興味のある方はこちらでチェックできます

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi- [0-9]。[0-9]。[0-9] [0-9] .tar.gz" | 並べ替え-u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreifこれは常に正しいバージョンを見つけることはありません（--preが提供されていない限り、pipはアルファ、ベータ、リリース候補などを無視します）。 これはより近いです（ただし、保証もありません）：
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

では、JSON応答には"pre-version": "1.2.3a4"のようなものが含まれているはずなので、単純な式で両方をgrepできます。

私はこの問題を本当に理解していません...これは何についてですか？

• pip installに新しいオプションを追加すると、パッケージが解決されるまでpipが実行され、選択したパッケージが印刷されて終了します（インストールをスキップします）。
• pip searchを使用するときに、パッケージ名の横に最新バージョンを表示しますか？
  
  
  
  • PyPIでパッケージの最新バージョンを見ることができますか？
  
  

後者は私には解決されたようで、前者はおそらく新しい専用の問題を取得する必要があります。

@pradyunsgさて、正しく思い出せば、現在利用可能なバージョン（リリースとプレリリースの両方）を確認する簡単な方法が必要でした。 このバージョンはpip install -U [--pre]によってインストールされます。

virtualenvを設定するスクリプトに必要でした。 パッケージの新しいバージョンがある場合、現在のバージョンを更新するか保持するかを尋ねられました。 したがって、このユースケースは新しいpip検索でカバーされます。

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

--download -非推奨バージョンを投稿...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

次のようなものを使用します。

pip install foo==

利用可能なすべてのバージョンのリストを提供します（有効なpypi利用可能なパッケージの場合、この場合は分子）：

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

しかし、実際にダウンロードしたり、dev / nullにインストールしたりせずに、pipを使用してインストールされるバージョンを取得できると便利です:-)

同意しました。 この機能のないパッケージマネージャーは一種の冗談です。 バージョンのリストを取得する例でさえ、このパッケージマネージャーにはないさらに別の機能を補うための完全なハックです。 意味があるとは言いませんが、これらは、完全に無視されているこのバグが作成された8年前に利用可能であったはずのことです。 ピップは、実際にはもっと多くの機能を備えているものに置き換えられると思いますが、ひどく、グロテスクで、途方もなく大きく、複雑すぎます。 まあ、私たちはいつでも自分で書くことができます。

pip-toolsはpipに基づくツールであり、このスレッドの人々が質問していることのいくつかに役立つと私は信じています： https ：//github.com/jazzband/pip-tools

抽象依存関係のリストを指定すると（つまり、バージョンが指定されていない場合）、インストールする各要件と依存関係の特定のバージョンが示されます。

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3-はほぼ同じくらいばかげています（インストールする必要がある別のものだと数えるともっとばかげています[python2サポートが必要な場合はさらにばかげています]）

さらに、pip-tools（＆pipenv）の全体的なポイントは、プレーンなpipと制約ファイルを使用して実行できます。 （ pip install -r reqs -c constraints; pip freeze > constraints ）。

pip installに新しいオプションを追加すると、パッケージが解決されるまでpipが実行され、選択したパッケージが印刷されて終了します（インストールをスキップします）。

ここで重要なハウスキーピングを実行しました。この問題は、このユースケースを追跡/議論することと、新しい機能に対するこの要求に対応するためにpipが変更されるかどうか/どのように変更されるかについてです。

関連するコンテキストが添付されていない非常に古いコメントから、このための仕事の90％を実行するための「潜在的なハッキング/スクリプトナゲット」を含むコメントまで、たくさんのコメントを非表示にしました。 後者のグループについては、後者の詳細をここに投稿しないでください。ツール自体に修正を実装する方法を議論するフォーラムではなく、これらの提案がより適切な他のユーザーサポートフォーラムがあります。 :)

実際にまだ関連性があり有用なコメントが隠されてしまった人にはお詫びします。 私は本当に多くのコメントの文脈を理解することができませんでした、そしてあなたのコメントは巻き添え被害に隠されたばかりかもしれません。

このチケットは依存関係リゾルバー（＃988）の開発によってブロックされているため、チームはこのテーマで前進するためにコミュニティからの支援を求めていることをここで言及したいと思います。

新しいリゾルバーが失敗する状況をよりよく理解する必要があるため、複雑な依存関係を持つpipユーザーに次のことを求めています。

1. 新しいリゾルバーを試してください（バージョン20.1を使用し、 --unstable-feature=resolverを実行します）
2. それを破る：P
3. 問題を提出する

あなたはここでより多くの情報とより詳細な指示を見つけることができます

このスレッドでまだ言及されていない＃7819の実験から生じたユースケースのひとつは、パッケージを後でダウンロードしてインストールするためのURLを具体的に記録することです。これは、上記のロックファイルとわずかに直交する機能です。大きなファイルをダウンロードせずにpipresolveの結果を消費する場合に特に便利です。

Twitterで大規模な、通常は機械学習アプリケーションのパッケージ化方法を開発してきました。これは「ipex」と呼ばれ、最初に実行されるまでサードパーティのコードを含まずに出荷できます（サイズが大幅に縮小されます）。 パンツビルド/パンツ＃8793の場合、要件を解決するためにpexランタイムライブラリを呼び出す実行可能なpexアーカイブを生成します（pexは内部でpipを実行します）。 私は現在、実行時に完全なpex / pip解決ステップを、ダウンロード元のURL（ req.link ）のみを記録する置換に置き換えるプロトタイプに取り組んでいます。 「ハイドレイテッド」pexファイルを作成するためのダウンロードとファイルコピーは完全に並行して実行できるため、これは実際には非常に高速です（そして非常にきめ細かくキャッシュできます）。

その機能（大量のホイール/非ホイールを並行してダウンロードしてインストールする）は、ロックファイルに入れるホイールまたは非ホイールのURLをさらに公開することに依存していますが、ここではまだ言及していません。 これにより、脱水されたipexファイルが作成されたときにパンツがpipを1回だけ呼び出すことができ（ダウンロードURLを解決するため）、IPEXファイルが最初に完全に呼び出されたときにURLを使用したその「解決」ステップの結果を消費して要件をダウンロードできます再度pipを呼び出す必要なしに別のマシン。

＃7819では、v1リゾルバーの内臓から出力にURLを伝播するために多くの労力が必要でした。 私が最後にv2リゾルバーで動作させようとしたときは、はるかに少ない労力でした。 今のところ、ダウンロードURLを吐き出す--dry-runまたはresolveコマンドの実験的なバージョンを社内で出荷することを計画しています。これが成功すれば、うまくいけば、その間に--unstable-feature=resolverの残りの問題！ ：D：D

おっしゃるように、ロックファイル形式の設計はリゾルバーの実装と直交しています。 ただし、現在のpipプロジェクトの範囲外であることも意味します。 このトピックについての議論がありましたが（警告：非常に長いスレッド）、利用可能な開発者の時間が不足していることを考えると、これは、リゾルバーが少なくとも安定する前に深刻な議論が行われない可能性が高いことを意味します。

リンクありがとうございます!!

2020年5月24日日曜日19：34Tzu-ping [email protected]
書きました：

あなたが言ったように、ロックファイルフォーマットのデザインは
リゾルバーの実装。 ただし、それはまた、それが範囲外であることを意味します
現在のpipプロジェクト。 トピックに関する議論がありました
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
（警告：非常に長いスレッド）が、開発者の時間の不足を考慮して
利用可能である場合、これは、真剣な議論が行われない可能性が高いことを意味します
リゾルバが少なくとも安定する前に発生します。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/53#issuecomment-633346918 、または
登録を解除する
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
。

@cosmicexplorer --dry-runまたはresolveコマンドの実験的なバージョンを社内に出荷しましたか？ もしそうなら、それはどうですか？

あなたは私がこの機能に非常に興味を持っていることに気づいたかもしれません😄

次のようなものを使用します。

pip install foo==

利用可能なすべてのバージョンのリストを提供します（有効なpypi利用可能なパッケージの場合、この場合は分子）：

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

しかし、実際にダウンロードしたり、dev / nullにインストールしたりせずに、pipを使用してインストールされるバージョンを取得できると便利です:-)

いいトリック!! 便利で便利!! 本当に印象的です!!

潜在的なハッキング/スクリプティングナゲット...後者の詳細をここに投稿することは控えてください-ツール自体に修正を実装する方法を議論するフォーラムではなく、それらの提案がより適切である他のユーザーサポートフォーラムがあります。 :)

本当に何のためでもありませんが、これはバグを非常に長く長引かせたときに起こるようなものです（私自身の最近寄稿された「ナゲット」の場合は7。56年ですが、このまだ開いているバグは現在9。25年です年）。 人々は回避策を共有します。

また、回避策を含むコメントを非表示にすることで、コメントに投稿しようとしている回避策が不要であることに気付くのに役立つとは思えません（一部、非表示のコメントをすべてクリックして、すでに言われていることを確認する人がいないためです）。 誰かが10年前のバグに遭遇し、メンテナからの何らかの進歩や指示、または回避策を見つけられない場合、他の人があなたの仕事を通して苦しむので、彼らは回避策を共有することが必要であるとあえて考えますすでに自分でやったことは不要です。

そして、はい、このコメントは、このまだ開いているバグに対応して行ったことが起こったときにも起こります。

心配しないでください。pipがスクリプトを再び壊し、このバグがまだ開いていない限り、私はこれ以上挑発されていないコメントを追加しません。

あなたがしてくれてありがとう。 :)

@brainwane @ ei8fdb UXの観点からこの問題を重要なものとしてフラグを立てたい-＃8377に関連

私の理解に基づく高レベルの要約：

• 新しいリゾルバーを使用すると、pipの許容度が低くなり、競合する依存関係のインストールが拒否されます（ ResolutionImpossible ）
• 依存関係の競合は、依存関係ツリーのどこにでも存在する可能性があります
• 既存のツール（pipdeptree pip-conflict-checker）は、すでにインストールされているパッケージのみを表示し、要求されたが失敗したパッケージは表示しません。
• 現在、依存関係の競合がパッケージのインストール前、またはResolutionImpossibleエラーが発生した場合（各プロジェクトの依存関係を手動で検査する場合を除く）をユーザーが判断する方法はありません。

つまり、ユーザーが最上位の要件（つまり、 requirements.txtで指定されたパッケージ、またはコマンドラインに直接入力されたパッケージ）に基づいて、依存関係の競合の可能性を検出する方法が必要です。

これを行うことにした場合は、提案されたフラグ名（ --dry-run ）を調査/検討する必要があります。

@uranusjr @ pfmoore-何か問題があったり、私たちの議論に基づいて何かを見逃したりした場合は、私を訂正してください。 どうも

@nlhkabu上記のすべてのコメントに同意します。 ただし、明確にするために、 --dry-runスタイルのコマンドを使用すると、ユーザーは依存関係の競合が発生するかどうかを確認できます。 ただし、説明したように、競合が存在する理由を診断する上で追加のヘルプは提供されません。 したがって、可能な場合はインストールするが、そうでない場合は何もせずにエラーを報告する通常の「許しを求める」アプローチとは対照的に、これは基本的に「飛躍する前に見る」インストールコマンドです。

これが提供しないもの、およびIMOが非常に役立つもの（pipサブコマンドとして、またはサードパーティツールと同じくらい便利）は、pipが機能している依存関係ツリーがどのように見えるかを一覧表示する方法です。 。 （これには、リゾルバーや実際のインストール手順は必要ありません。パッケージソースからの依存関係メタデータを「単純に」推移的に一覧表示します）。

これは、 pip resolveコマンドの形式を取ることもできます。

pip resolveは、ほとんどの人が期待するものです。それを呼んでください😄最終的には独自のフラグも使用できるようになります。

明確化@pfmooreをありがとう。 ユーザーの観点から、 resolveなしで$ --dry-runがどれだけ使用されるかわかりませんか？

IMO、エラーが発生することをユーザーに伝えるだけでは不十分です。また、エラーがどこにあるかを見つけて何かを行うために十分な情報をユーザーに提供する必要があります。

したがって、ユーザーが--dry-runを実行していると想像してください...応答に次のようなものを含めることができます。

依存関係の競合が検出されました。 pipはd1.0およびc1.0をインストールできなくなります。
競合の原因は次のとおりです。
d1.0はE == 2.0に依存します
c1.0はE == 1.0に依存します
pip resolveを実行して、依存関係ツリーを調べます。

ResolutionImpossibleエラーメッセージ（＃8377を参照）でpip resolveを再利用することもできますが、これは大きなメリットになります。

@pradyunsg pip resolveの別のチケットはありますか？

@nlhkabu https://github.com/pypa/pip/issues/7819

また、明確にするために、 pip resolveの使用目的は、次のいずれかであると思います（成功を想定）。

1. 出力をファイルにリダイレクトする（通常はコミットされます）、または
2. 他のツールは出力を使用/解析します

Twitterの場合、＃7819で説明されている「ipex」ツールを使用して、 pip resolveコマンドを使用して実行可能なpexファイルを作成しています。このコマンドは、何かをダウンロードする代わりに、解決されたすべてのディストリビューションのダウンロードURLを出力します（まだ本番環境では使用されていません） ）。 これは、他のいくつかの最適化（＃8448など）とともに、これらのipexファイルを数秒で作成できるようにします。 これらのipexファイルは、同じデータセンター内から、最初に実行されたときにpip resolveコマンドから出力されたすべてのディストリビューションをダウンロードします。これにより、ipexファイル自体をギガバイトではなくメガバイトにすることができ、アップロード時間が短縮されます。多くの地域から。

したがって、基本的には、 pip resolve出力のjsonバージョンをファイルとしてpexアーカイブに埋め込み、ブートストラップスクリプトでそれを読み取って、ディストリビューションを並行してダウンロードします。

これに関する更新はありますか？

誰かが最初に解決結果を提示する方法を理解する必要があります。 現在、リゾルバーの作業に携わっているAFAIKピップメンテナーは全員、リゾルバー自体の改善に取り組んでいるため、前進するには外部からの支援が必要になります。

私が間違っている場合は訂正してください。ただし、次のことが当てはまるようです。

• Pythonパッケージのインストールには、setup.pyの実行が含まれます。
• --dry-runオプションがないと、pipのリゾルバーがインストールを選択するパッケージを簡単かつ信頼性の高い方法で知ることはできません。

したがって、 pip installを実行するということは、簡単で信頼性の高い監査方法がなくても、自分のマシンで任意に選択したPyPIパッケージからコードを実行することに同意することを意味するように思われます。 その選択は、個々のパッケージ作成者の依存関係の選択とセキュリティ慣行に再帰的に依存します。

インストールするプロジェクトとバージョンにソースディストリビューション（sdist、setup.pyが含まれる）のみがあるか、ホイール（ビルドされたディストリビューション、メタデータテキストファイルが含まれる、任意のコードが実行されることなくファイルコピーによってインストールされる）があるかによって異なります。

--dry-runを使用しても、pipは、ホイールを持たないパッケージ（setuptoolsの場合はsetup.pyの実行を含む）のビルドバックエンドを実行する必要がある可能性があります。