「upgrade」は、「install--upgrade」の簡単なエイリアスです。 もう少し考える必要があります
「アップグレード-すべて」について; 一つには、パッケージをアップグレードするだけだと思います
sys.prefix内？ （つまり、virtualenv内にいる場合は、
グローバルパッケージをアップグレードします）。 それが引っ越す理由になります
UninstallPathSet.can_uninstall（）をより一般的な名前の関数（または
InstallRequirementのメソッド）なので、一般的な「これに触れることはできますか？」
決定。

Original Comment By: Carl Meyer

記録のために、私はそれがする能力を考えると良い考えのように思えると思います
アップグレードする前にアンインストールしてください。 私は--allオプションを好むが
独自のupgrade-allコマンドの代わりにupgrade 。

can_uninstall（）に関しては、私は同意します。これはおそらく持っていると便利です。
とにかくグローバルに。

Original Comment By: Jannis Leidel

install--upgradeのエイリアスとしてアップグレードすることに完全に反対しているわけではありません。 しかし
少し些細なことのようです。

アップグレード-すべて、「アップグレード可能」とは何かを理解する必要があります。 おそらく1つ
前提条件はそれが住んでいることです/lib/pythonX.Y/site-packages
（単にsys.prefixの下では十分ではありません）。

「zipインポート」のようなものを許可する場合（親からパッケージを取得するため）
環境をvirtualenv環境に）そしておそらくその中にパッケージ化する
親環境をアップグレードするべきではありませんが、それが何であるかは100％明確ではありません
ユーザーは期待します。

「pipアンインストール」で編集可能なパッケージをアンインストールしてみましたが、かなり
.egg-linkを削除し、easy-install.pthを更新することを合理的に提案しました。 しかし、それは
パッケージを合理的にアップグレードできなかったため、can_uninstallは多少
can_upgradeとは異なります。

Original Comment By: Ian Bicking

ええ、あなたは正しいですcan_uninstallとcan_upgradeは異なります。

「pipimport」があったとしても、アップグレードしたくないと思います
インポートされたグローバルパッケージ。 しかし（編集可能なものと一緒に）それは「
この警告をコンソールにアップグレードします。

Original Comment By: Carl Meyer

このバグの+1

Original Comment By: smyrman

問題＃167は、この問題の重複としてマークされました。

Original Comment By: Carl Meyer

1

(echo pip; pip freeze | awk 'BEGIN{FS="=="}{print $1}') | xargs sudo pip

インストール-U

これにより、インストールされているすべてのパッケージ（pip自体を含む）がアップグレードされます。 もしも
virtualenvで実行する場合、おそらくsudoを使用する必要はありません。

もちろん、失敗のリスクが高くなります-パッケージの1つをアップグレードする場合
失敗するとプロセス全体が失敗します（のport upgrade outdatedに似ています
MacPorts）。

Original Comment By: Tomasz Elendt

アップグレードの+ 1--all

なぜ現時点ですべてのPythonモジュール管理機能がダメなのですか？ なんでだめなの
1つは単純なアップグレード+アップグレード--allコマンドを提供しますか？

Original Comment By: Anonymous

実装を試してみてもかまいませんが、最初にいくつか質問します。

'--all'をサポートする新しい「アップグレード」コマンドの一般的なコンセンサスです
オプションをpipに追加しますか？

pipアップグレードの実行は、それが実行されている環境にのみ影響するはずです。
virtualenvから実行すると、そのenvにローカルなパッケージのみがアップグレードされます。
非virtualenvの場合も同じです

Original Comment By: Kelsey Hightower

ケルシー：上記の議論を読んだところ、本当のことは何も見えません
それに反対。 作るのは素晴らしい追加だと思います。 メインエッジケースは
編集可能なVCSのインストール-Ianが提案したように、「アップグレード」コマンドだと思います
それらに触れてはいけません。 すべてのコンテキストで「アップグレード」が何を意味するかを定義する
編集可能な可能性（ローカルリポジトリがインストールされ、編集可能であり、
起源）はほぼ不可能だと思います、そしてたとえ中途半端に働いていたとしても
定義をまとめることができます、それはメンテナンスを増やすだけです
すでに脆弱なVCSバックエンドの負担。 ただし、編集不可能な場合は、
それ！

Original Comment By: Carl Meyer

カール：かっこいい、始めてこのチケットを結果で更新します。

Original Comment By: Kelsey Hightower

アップグレードコマンドの作業中に、次の質問が出てきました。

• どのパッケージを指定するためにアップグレードサポートを
  アップグレードしますか？ 要件ファイルをサポートする必要がありますか？
• pipアップグレードはまだインストールされていないパッケージをどのように処理する必要がありますか？
  不足しているパッケージをインストールする必要がありますか？

pipアップグレードのユースケースとその処理方法：

# pip upgrade some_installed_package

Try and locate a package that satisfies the requirement. If the

要件が満たされていない要求されたバージョンへのアップグレード。 これも
古いバージョンへのアップグレード。

# pip upgrade --all

Locate all installed packages (non-editables) and update them to a new

利用可能な場合はバージョン。

# pip upgrade some_other_package

Warning: some_other_package not installed, use pip install

some_other_package。

私の目標は、アップグレードコマンドを本当にシンプルに保つことです。 アップグレードできます
新しいバージョンまたは古いバージョンへの特定の編集不可能なパッケージ。 またはアップグレードできます
編集不可能なすべてのパッケージを新しいバージョンに。

考え？

Original Comment By: Kelsey Hightower

「pipupgrade」は「pipinstall--upgrade」の正確なエイリアスである必要があると思います。
今は動作します。 これは、はい、要求されたパッケージをインストールすることを意味します。
インストールされていません。はい、-rを使用して要件ファイルを受け入れます。 彼のはず
ほとんど新しいコードなしで実行可能です。

アップグレード--allは、現在のリストを見つけるためにいくつかのコードを必要とします
インストールされたアップグレード可能なパッケージ。 次に、そのリストを渡してインストールする必要があります
-上記のようにアップグレードします。

Original Comment By: Carl Meyer

カール、返事ありがとう。 私はあなたが持っている道をかなり進んだ
説明された。 今日の後半に、いくつかの実行例を投稿できるようになるはずです。

Original Comment By: Kelsey Hightower

コードのほとんどを完了しました。コードを投稿する前に少し磨きをかけます
レビュー用。

TODO：

• テスト
• フィルタ要件ファイル。 編集不可能なものをパッケージのリストに追加します
  アップグレード。

upgradeコマンドを使用してpipを実行する

# pip upgrade --all

All packages up-to-date


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML

Package updates available:

  PyYAML: N/A (installed) 3.09 (latest)

Downloading/unpacking PyYAML

  Downloading PyYAML-3.09.tar.gz (238Kb): 238Kb downloaded

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  PyYAML: 3.09 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML==3.08

Downloading/unpacking PyYAML==3.08

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

Package updates available:

  PyYAML: 3.08 (installed) 3.09 (latest)

Downloading/unpacking PyYAML

...

Successfully installed PyYAML

Cleaning up...

  Removing temporary dir /root/upgrade_env/build...

Original Comment By: Kelsey Hightower

最後の一連の質問（私は願っています）：

• pipアップグレードで要件ファイルを解析し、
  編集可能？ URL要件はどうですか？

要件ファイル内の編集不可能なアイテムごとに、
それ以降のバージョンのインデックス。 これを行うには、私は収集する必要があります
要件ファイルの各行のパッケージ情報。

ヒントは大歓迎です（現在、 pip.req.parse_requirementsを参照してい

• pip upgradeは、インストールする
  （これは私が今していることです）。 そうでない場合、アップグレードコマンドはどのように決定する必要がありますか
  アップグレードがある場合は？

現在、アップグレードリストにパッケージを追加しているのは次の場合のみです。

• パッケージがインストールされていません
• アップグレードが利用可能であり（インデックスからの最新バージョン）、明示的ではありません
  バージョンが要求されました
• 要求されたバージョンは、インストールされているバージョンとは異なります（バージョンミス
  マッチ）。
• フィルタするまで、要件ファイルをインストールコマンドに延期しています
  編集不可能な要件を削除します。

Original Comment By: Kelsey Hightower

カールはあなたの投稿を読み直した後、私は何よりも多くのことをしているようです
必要。 ブランチをアップロードして、ご覧ください。 行ったかもしれない
新しいバージョンのPyPiをチェックして船外に出ます。

Original Comment By: Kelsey Hightower

カールはあなたの投稿を読み直した後、私は何よりも多くのことをしているようです
必要。 ブランチをアップロードして、ご覧ください。 行ったかもしれない
新しいバージョンのPyPiをチェックして船外に出ます。

Original Comment By: Kelsey Hightower

ええ、あなたは必要以上のことをしているようですね。 ピップインストール
--upgradeは、すでに話し合っているすべてのことを実行します（新しいものをチェックします）
バージョンなど）; すべての「pipアップグレード」は、2ライナーパスのようなものでなければなりません
すべてをpipinstall--upgradeに変更します。

ここに記述される唯一の実際のコードは、「upgrade--all」を取得するためのコードです。
環境にインストールされているアップグレード可能なパッケージの完全なリスト。

Original Comment By: Carl Meyer

ええ、私はそれを知っていました。 まあ、私はたくさん学びました。 これには必要ありませんが
タスク、私はインストールされ、利用可能なものを表示する機能が好きです
アップグレードプロセス（上記のテスト実行を参照）。

リファクタリングしてクリーンアップします。 上の私のフォークの現在の変更
upgrade-コマンドブランチ。

https://bitbucket.org/khightower/pip/changeset/2bdc202b446c

Original Comment By: Kelsey Hightower

カールの提案に従ってアップグレードコマンドを削除しました（私は遠くまで行きました
そもそも）。 結果が気に入ったかどうかはわかりませんが、ミラーインストールは行います-機能の

pipは、次の場合でもパッケージをダウンロードして再インストールしようとしているようです。
パッケージはすでにインストールされており、最新です。 アップグレードするとさらに悪い--all 、pipはpip自体を含むすべてを再インストールします。 これはどのようにピップですか
アップグレードは機能するはずですか？ もしそうなら、私はほとんど完了です:)

pipupgradeコマンドの実行

# pip upgrade Mako


Downloading/unpacking Mako

  Running setup.py egg_info for package Mako


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

Downloading/unpacking MarkupSafe>=0.9.2 (from Mako)

  Running setup.py egg_info for package MarkupSafe


Installing collected packages: Mako, MarkupSafe

  Found existing installation: Mako 0.3.6

    Uninstalling Mako:

      Successfully uninstalled Mako

  Running setup.py install for Mako

    changing mode of build/scripts-2.7/mako-render from 644 to 755


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

    changing mode of /root/upgrade_env/bin/mako-render to 755

  Found existing installation: MarkupSafe 0.11

    Uninstalling MarkupSafe:

      Successfully uninstalled MarkupSafe

  Running setup.py install for MarkupSafe


    building 'markupsafe._speedups' extension

    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall

-Wstrict-プロトタイプ-fPIC-I / opt / OpenPython-2.7.1 / include / python2.7 -c
markupsafe / _speedups.c -o build / temp.linux-x86_64-2.7 / markupsafe / _speedups.o

    gcc -pthread -shared

build / temp.linux-x86_64-2.7 / markupsafe / _speedups.o -o
build / lib.linux-x86_64-2.7 / markupsafe / _speedups.so

Successfully installed Mako MarkupSafe

Cleaning up...

Original Comment By: Kelsey Hightower

Kelsey-ええ、install--upgradeにはいくつかのバグがあります。 特にあなた
＃13を特定し、パッケージを再ダウンロードして再インストールすること
すでに最新です。 何か違うことをする必要はありません
新しいupgradeコマンドを使用すると、install--upgradeのバグを修正できます。

アップグレード--allを使用すると、pipがそれ自体をアップグレードすることは私には合理的であるように思われます
利用可能なアップグレードがある場合も同様です。 （個人的にはアップグレードを使用しません
-すべてなので、それを使用する人々がそれからどのような行動を望んでいるのかわかりません
ここ）。 明らかに、 ＃13が修正された場合は、より良い動作になります。

Original Comment By: Carl Meyer

カールに感謝します、私はこれをまとめて＃13を見始めます

Original Comment By: Kelsey Hightower

時間があれば、私のアップグレードコマンドブランチを確認してください。 その間
既存の単体テストを複製しないようにする単体テストに取り組みます
インストールコマンド。

https://bitbucket.org/khightower/pip/src/fa7b2a6d2bf1/pip/commands/upgrade.py

Original Comment By: Kelsey Hightower

@vababiy ：私はあなたのupgrade-commandを試しましたが、正しく動作しないようです...それで私は自分のものを作りました：

https://github.com/pypa/pip/pull/313
https://github.com/jedie/pip/commit/7a31d70dabe0e809184fe1b5280c5a7ccf420dd5

@ jedie @ khightowerにコメントを送るつもりだったと思います。 @vbabiyはコメントをここに移行しましたが、upgradeコマンドを記述しませんでした。

+1

@kelseyhightower何か進歩はありますか？

+1

+1！

+1

+1

「+1」だけで問題についてコメントするのはやめてください。 この機能が必要であることは承知していますが、受信トレイにスパムを送信しても効果はありません。

代わりに、「パッチが完了しました」というコメントを見てワクワクします。 ;）

+1

更新はありますか？ これを追加する予定はありますか、3歳になりました。

@pradyunhttps ： //github.com/pypa/pip/issues/59#issuecomment-9418336を参照してください

+1

これはもうマージされていると思いました。 私は自分のPythonスキルをほこりを払い、もう一度やり直すことができます。

この機能は1.5に含まれますか？ 1.5のドキュメントでそれへの参照を見つけることができません...

+1

この問題の状況はどうなっていますか？

＃988でブロックされています

それがあなたにとって本当に重要である場合、すべてのパッケージをアップグレードするための回避策があります。 私はそれを並行して行うためのスクリプト（https://github.com/ariccio/update-pip-packages）をまとめましたが、インターネット上の他の場所にも多くの実装があります。

この問題には2つの部分があります。 upgrade-allはgh-988によってブロックされる可能性がありますが、 upgradeがどのようにブロックされているのかわかりません。 pip upgradeは、 pip install -U --no-deps単純なエイリアスにすることができます。 これにより、setup.pyファイルでinstall_requiresを使用する際の主な問題の1つが解決されます。 これはすぐにできませんか？

pipアップグレードは、pip install -U--no-depsの単純なエイリアスにすることができます

説明から：

pip upgradeのようになりますpip install --upgradeそれは、デフォルトでは非再帰的（および提供するであろう除き--recursiveオプション）。 現在の再帰的なデフォルトの動作は、多くの人に悲しみをもたらしています（＃304）。 今すぐ非再帰的なアップグレードを行う方法については、こちらをご覧

それはpip install -U --no-depsではありません

この文脈での「非再帰的」とは、単に–no-deps意味するのではありません。 非再帰的なアップグレードは依存関係をアップグレードしますが、親の要件を満たすために必要な場合に限ります。

@qwcode説明してくれてありがとう。 それは私が気にかけていることではありません。 なぜこれを「非再帰的」と呼ぶのでしょうか。それでも再帰的ですが、少し賢く/異なっていますか？

gh-571での議論から、本当に非再帰的が望ましいデフォルトであるという印象を受けました。 それは確かに理にかなっており、 https：//github.com/scipy/scipy/commit/8e7ee0c4b3c16のようなコードを常に書く必要が

＃571では、「非再帰的」は--no-depsではなく、あなたが言うように「よりスマートで異なる」再帰的です。
そのPRからのtest_upgrade_with_needed_recursive_upgrades()テストに注意してください。

条件にとらわれることなく、3つのことがあります：

1. 「よりスマートで異なるアップグレード」、つまり、依存関係のアップグレードを意味する可能性のあるOSパッケージで発生する種類（ただし、実際にアップグレードが必要な場合のみ）。
2. pipが現在行うことは、必要性や競合の解決に関係なく、すべての依存関係をアップグレードすることです。
3. --no-deps

＃1と＃2を区別するためのいくつかの可能な方法

1. 「非再帰的」と「再帰的」
2. 「通常」と「再帰」
3. 「再帰が必要な場合のみ」と「再帰に関係なく実行する」

私は最高の用語を使用することにオープンです...それらが何であるかはわかりません。

この「必要な場合にのみ再帰的」というフレーズが好きだと思います。 多分私はここのドキュメントでそれを使うべきです：

私も好きです。 3つのオプションをすべてまとめて説明するとします

a. non-recursive
b. only if needed recursive
c. recursive (or "do it regardless recursive")

それは明らかだろう。

次に、適切なデフォルトを選択します。 upgradeとinstall -U両方について、（a）または（b）のいずれかが意味をなします。 私は（a）を強く好みますが、OSパッケージングが行うことを考えると、（b）も理にかなっています。

（c）デフォルトとしては意味がないので、 install -Uを変更しないという決定を再検討してください。

私が（a）を強く好む理由を明確にするために、（b）を望んでいて（a）を取得している無防備なユーザーは、 "non-recursive upgrade can't satisfy all dependencies, please use only-if-needed recursive"というメッセージを読む必要がありますが、これはそれほど大きな問題ではありません。 デフォルトが（b）の場合、その疑いを持たないユーザーは、実際には触れたくないパッケージのアップグレードまたはインストールの失敗に終わる可能性があります。 回復には数時間から数日かかる場合があります。

（c）デフォルトとしては意味がないので、install-Uを変更しないという決定を再検討してください。

install -Uをそのままにしておく理由は、互換性の理由だけであり、最終的には非推奨になります。

デフォルトが（b）の場合、その無防備なユーザーは最終的にアップグレードされる可能性があります
または彼が本当に触れたくなかったパッケージの壊れたインストールでさえ

ユーザーが必要な依存関係のアップグレードを実行しないようにしたい場合は、特に--no-depsを使用してそれを要求する必要があります。 私の頭の中には、これまでデフォルトになる方法はありません。 その振る舞いは、あなたが考えているものよりも多くのダメージを与えるでしょう（これは外れ値の場合です）。 何度も何度も、ユーザーは必要な依存関係のアップグレードを持っていないままになります。

install -U廃止

（b）は（a）よりも一般的であることに同意します。 それが100倍一般的であるとしても、私が思うにそうではありませんが、それ以上のダメージは真実ではありません。 インストールを開始する前に明確なエラーメッセージを読むことは、たとえば途中でコンパイルエラーを実行するよりもはるかに優れているため、imho（a）が依然として適切なデフォルトです。

--no-deps依存することは、経験豊富なユーザーにとっては問題ないかもしれませんが、新しいユーザーは、問題が発生した後にのみそれについて学ぶことになります。

とにかく、私はあなたを納得させることができないようです。 その後、マニュアルに戻ります

try:
   import dependency
except ImportError:
    install_requires.append('dependency')
else:
    if dependency.version < 'x.y.z':
        raise ValueError('Please upgrade dependency to x.y.z')

です。

@qwcode詳細な説明をありがとう。 これが近い将来に前進することを願っています-必要な場合にのみ、再帰的に現在の動作を大幅に改善します。

今週もinstall_requires使用しない理由について問題を解決するために何時間も費やし、現在の動作から離れるために：+1：を追加します。

この問題に関する更新はありますか？

2015年になりましたが、 pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U stackoverflowからコピーする必要があります

ええ、本質的にすべての進歩はこの問題に関連しています。

GitHubは、物事を相互参照するのに非常に優れています。 それらはすべてクリック可能です！ （あなたはこれを知っていると確信していますか？）

確かにそうですが、この「シンプルな」機能にこのような遅延がある理由はわかりません。

これの理由は何ですか？

アム2015年4月16日5時28 umのschriebアレクサンダー・リッチオ[email protected] ：

ええ、本質的にすべての進歩はこの問題に関連しています。

GitHubは、物事を相互参照するのに非常に優れています。 それらはすべてクリック可能です！ （あなたはこれを知っていると確信していますか？）

—
このメールに直接返信するか、GitHubで表示してください。

pip upgrade-allに関しては、コンセンサスは、＃988に関連する作業を待ってから、最終的に欠陥があり、作業環境に危険を及ぼす可能性のある光沢のある新しいコマンドをリリースすることであるようです。 要件を適切に解決しない単純なバージョンのupgrade-all 、既存のパッケージを簡単に壊してしまう可能性があります

+1

4年間何をしていますか？

+1

+1

+1

@muhasturk現在待機中... https：//github.com/pypa/pip/issues/59#issuecomment -93646462

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 ...スパムで申し訳ありませんが、 pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U痛いです！

+1

誰かがこれに取り組むことに興味がある場合、上記のコメントはやや混乱していると思います-AFAICTの実際の状況は、現在、適切な依存関係解決システムの必要性によってpip upgrade-allがブロックされていますが、 pip upgradeはいつでも実装できます。 誰かがその部分に取り組みたいのなら、それは非常に素晴らしいでしょう:-)。

（ここから始まるスレッドと@dstufftの返信も参照してください。また、上記の評価に同意するコメントをここに付けて

1年前のpypa-devリストからの別の議論があります（これはpip upgrade FOOが今できることに同意します）

ありがとう@qwcode！ また、 https： //pip.pypa.io/en/latest/user_guide/#only -if-needed-recursive-upgradeで新しい説明を見たところ、役に立ちました。

+1

私が間違っていない場合：

xxxがインストールされていない場合：

• pip upgrade xxxはpip install xxxと同等です
• pip upgrade xxx --recursiveはpip install xxx --upgradeと同等になります

xxxがインストールされている場合：

• pip upgrade xxx --recursiveは、引き続きpip install xxx --upgradeと同等です（設計による）
• しかし、現在pip upgrade xxxに相当するものはありません。これは、 pip install xxx --upgrade-only-if-needed/--upgrade-lazy可能性があります。

pip install新しいオプションを追加することで、新しいコマンドの付加価値が何であるかが明確ではありませんか？

pip install新しいオプションを追加することで、新しいコマンドの付加価値が何であるかが明確ではありませんか？

デフォルトのpip install -U動作は、多くのプロジェクトでは受け入れられません。 上記の私のコメント（https://github.com/pypa/pip/issues/59#issuecomment-52434862）を参照してください。 そしてここにもっと長い説明があります： http ：

受け入れられない場合は、pip install --upgradeの使用法をpip upgradeに変更する予定ですか？
代わりに、現在のpip install --upgradeusageをpipinstall --upgrade-only-neededに変更できないのはなぜですか？
新しいコマンドは、新しいオプションができなかったことを何を提供しますか？

それはすべて牛の小道を舗装しています。 彼が心配しているのは@rgommersの個人的な使用法ではなく、彼のユーザーです。 よくわからない場合、人々は「明白な」答えにたどり着くでしょう。そして今のところ、明白な答えはPythonエコシステムのいくつかの主要な部分にとって問題があります。

それはそう。 人々はドキュメントを読みません。 実際、見つけたすべてのインストールドキュメントを修正しますが、ユーザーが-Uまたは--upgradeを見るとすぐに、それを使用します。 人々が--no-depsや--only-as-neededなど、真剣に噛まれる前に何かを使用する可能性はほとんどありません。

代わりに、現在のpip install --upgradeusageをpipinstall --upgrade-only-neededに変更できないのはなぜですか？

そして明確にするために：私たちはpip install --upgradeを避け、このためにinstall_requires使用しません。 それはそれがどれほど悪いかです。

ここに小さな誤解があると思います-IIUC @ xavfernandezは、非再帰的なアップグレード機能を追加することに同意します。彼らの質問は、その機能のUIが、 pip install新しいオプションではなく、新しいトップレベルコマンドである必要がある理由です。

@xavfernandez ：現在、この機能の最も明確なUIについて、＃3194で議論が行われていることに注意してください。

（そして、 pip install -Uは非推奨になり、その後削除されるため、ユーザーがそれを使用しないことをどのように知るかについての質問に答えます:-)）

ここにちょっとした誤解があると思います

ないことは間違いありません。 そして、はい、私たちはUIについてのみ議論しています。 しかし、それは重要です。

うん、UIについて議論しているだけで、それが重要であることに同意します。 しかし、私が見ているのは、pipのアップグレードが終了すると、pipinstallを使い続ける理由がなくなるということです...
また、パッケージをインストールするためのUIは「pipupgradefoo」になります

pipinstallを使い続ける理由はありません

なぜ問題なのですか？ pip install --upgradeを正しい動作に変更する際の問題（少なくとも上記のコメントの損なうことです。 したがって、 pip upgradeは、ブレークを回避し、正しいデフォルトを取得する方法です。

@rgommers ：公平を期すために、 fooインストールされていないのに、なぜpip upgrade fooを実行するように指示されたのかについて、ゼロ以外の数の混乱した質問が表示されます。動作しません（コマンドが動作しないと想定して実行したふりをするのではなく、実際にコマンドを実行しようとするまで、前後に議論します）

＃3194で、おそらく正しい方法は、 --upgradeからpip install --upgradeを削除し、 pip install常に明示的に名前が付けられたアイテムのアップグレードを実行させ、デフォルトにすることであるとコメントしました。アップグレード時の現在の動作を取得するために、 --recursiveフラグを使用した依存関係の最小限のアップグレード戦略に変更します。

私は＃3194 UXになるだろう、デフォルトでのように感じることに同意すると思いますpip upgrade fooの代わりにpip install [-U] foo 。 私が抱えている唯一の問題は、2つのコマンドを使用するのはちょっと混乱していると思います。また、 pip upgradeが人々が使用するのに「正しい」コマンドであると考えると、明白なコマンドを使用するのは厄介だと思います。名前は間違った名前になります。

私は片頭痛を持っているので、完全に正しいとは言えないかもしれませんが、その提案への非推奨の道をどのように処理するかを考えているような気がします。

さて、ここでは後方互換性が重要であるとは主張しません。 私は常にpip install --upgradeの動作を変更することに賛成@ qwcodeによって拒否されたように見えたので、 pip upgradeが次善の策でした（1年前にpip開発者によってすでにOKされました）。

pip installデフォルト/動作の変更に戻りたい場合は、すばらしいです。

@dstufftそれは私には完全に理にかなっています-頭痛はそれほどひどいことはありません:)

--upgradeを非推奨にすることに同意したので、それを維持し、pip installに2つのオプションを追加できます：-upgrade-only-neededと--upgrade-eager、2番目は非推奨の--upgradeのエイリアスです

@xavfernandezユーザーに決定を強制することは、一種の--upgrade-only-neededと--upgrade-eagerが必要かどうか本当にわかりません。

@xavfernandezなので、最終的な状況では、コマンドはpip install --upgrade-only-neededなると提案していますか？ 醜いようです。

npm 、 hex 、 Cargoなどで利用可能なセマンティックバージョンのピン留めに相当するものにマップするものがある方がはるかに良いでしょう。 （a） PEP 440バージョンはセマンティックバージョニングに正確にマッピングせず、正確にマッピングできないため、（b）Pythonコミュニティ全体は、リリース内でもセマンティックのようなバージョニングに必ずしも対応していないため、Pythonコンテキストで調整する必要があります。 PEP440。

それでも、特定のバージョンを固定するという概念と同様に、これらの線に沿った何かが非常に役立ちます。

制約を考えると、短期的には、1つの実行可能なオプションは自作のupgradeおよびupgrade --allコマンドに類似したことを行う可能性があります。 ）。

ただし、長期的には、Pythonパッケージングコミュニティでバージョンが何を意味するかについての共有規則を作成することは非常に有用であり、その周りにpipサポートを構築することがその大きな部分になる可能性があります。

明らかな移行パスは次のとおりです。

pipバージョンX：

• オプションに追加しますpip install --eager 、 pip install --no-eagerところ、 --eagerがないバージョンの制限と要件については、我々はすでにいくつかのバージョンがインストールされている場合でも、最新バージョンをインストールしようとすると接続手段は、および--no-eagerは、いずれかのバージョンがインストールされていれば満足していることを意味します
• また、現在の-Uセマンティクスでオプションpip install --eager-recursiveを追加します
• --no-eagerはデフォルトのままです
• これらのオプションのいずれも指定されておらず、 pip installバージョン番号が添付されていない要件が渡され、この要件がすでに満たされている場合は、パッケージをアップグレードしなかったことを示す警告を出力しますが、将来的には現在の動作を維持したい場合は、 --no-eagerを使用する必要があります
• pip install -U非推奨の警告を追加して人々にpip install --eager-recursiveを紹介する

pipバージョンY：

• デフォルト切り替えるpip installへの--eager

pipバージョンZ：

• pip install -U削除します

私は--eager望んでいるので、YとZの異なるバージョンを作成しました。これにより、多くのドキュメントですでに参照されているため、 pip install -Uを少しの間維持しながら、より積極的なスケジュールでその変更を行うことができます。それに、それは害を引き起こしません。 しかし、明らかにY = Zはオプションです:-)

@chriskrycho ：それはすべて素晴らしいことのように聞こえますが、この議論は、ユーザーがパッケージの最新バージョンへのアップグレードを明示的に要求しようとしている状況を処理する方法についてです。これは、今日すでに一般的に発生している状況です。良い答えはありません。 ピン留めのサポートを要求するバグが開いているかどうかはまだわかりませんが、そうでない場合は、開始する必要がありますか？

絶対; 私のポイント（私は今では完全に明示することができなかったことを認識しています！）は、ここで採用されたソリューションが将来その種のタックを取ることと矛盾してはならないことに注意することでした。

pipの通常の非推奨パスは何ですか？ 時間/バージョンベース？ 削除する前に、どのくらいの期間非推奨にする必要がありますか？

ちなみに「熱心」という言葉は、ユーザーにはわからない言葉だと思います。 再帰的/必要な場合のみ再帰的/常に再帰的の方がはるかに明確です。

通常、2つのバージョンの非推奨サイクルを実行します。

私が想定しているメジャーバージョン？ マイナーバージョンは本当に高速です（7.0-> 7.1は1か月でした）。 通常、メジャーバージョンの間隔は半年です。1年間の非推奨の警告ですか？

ええ、ごめんなさい。 メジャーバージョン。 8.xで何かを非推奨にすると、8.xの残りの部分では黄色の警告になり、9.xのすべてでは赤い警告になり、10.xで削除されます。

ありがとう。

@dstufftのコメントをhttps://github.com/pypa/pip/pull/3194#issuecomment-152357835からコピーし

tl; drは、「デフォルト」の動作を修正する必要があると完全に考えていると思います。修正の特定の実装を決定する必要があります。

1. UXをpipinstall --upgradeのままにして、デフォルトを変更します。
2. UXを「正しい」デフォルトのpipアップグレードに移動し、-recursiveフラグを追加します。
3. UXをpipinstallに移動し、-upgradeを削除して、-recursiveフラグを追加します。

私の2c：

（1）UXが優れているので、今すぐ実行できます
（2）少し悪いUX（ installとupgrade両方があります）は、今すぐ実行できます
（3）2番目に優れたUX、 pip install変更--upgrade削除は10.0でのみ実行されます（8.0および9.0では非推奨）。

（1）の後方互換性の問題（どちらの方法でもマイナーなはずです）が（3）の場合よりも悪い理由がわかりません。 したがって、（1）が最適のようです。 bw compatが本当に心配な場合は、（2）を選択します。

とにかく、それを夜と呼ぶ時間。

（3）と（1）の違いは、インストールまたはアップグレードが最も一般的な操作であると考えるかどうかにあると思います。そうであれば、（3）のように短いコマンドにするのがおそらく最善です。 どちらにしても大したことではありません。

ちなみに「熱心」という言葉は、ユーザーにはわからない言葉だと思います。 再帰的/必要な場合のみ再帰的/常に再帰的の方がはるかに明確です。

私は「熱心な」つづりにはまったく執着していませんが、再帰は、アップグレードのオンとオフを切り替えるための主な言葉としては意味がありません。 --upgrade-non-recursive （将来のデフォルト）、 --upgrade-recursive 、 --upgrade-noneなどを使用できると思いますが、それでも混乱を招く再帰的な動作を前景にしています（ --upgrade-non-recursive何であるか--upgrade-non-recursiveは、レガシー-Uオプションの奇妙な再帰的動作にまだ慣れていない場合を意味します）、 --upgrade-noneは、自己を維持するために必要な場合でも、パッケージがアップグレードされないようにするように誤解を招くように聞こえます-一貫性。

このルートを使用する場合、ほとんどの人が望むオプションはデフォルトであり、再帰アップグレードとアップグレードなしのオプションはどちらも、ほとんどのユーザーがめったに使用しない特別なものであるため、スペル期間についてはあまり気にしません。無視できます。

--upgrade-non-recursive （将来のデフォルト）..。

もちろん、それは紛らわしいです。 しかし、あなたはこのスイッチをまったく提供しないという最も単純なオプションを無視しています。 デフォルトの動作と同じである場合、なぜそれが必要になるのでしょうか。

（3）と（1）の違いは、インストールまたはアップグレードが人々が望む最も一般的な操作であると考えるかどうかにあると思います

「インストール」を期待します。 少なくとも、私は意図的に頻繁に使用するパッケージのみをアップグレードすることを知っていますが、何か面白い/便利なものを見るたびに、それは単にpip install pkgname離れています。

（私は典型的なユーザーではないので、私の期待は間違っている可能性があります）

私は賛成すると思います：

• pip installエイリアスとなる新しいpip upgradeはありません
• pip install （ --upgrade*オプションなし）の動作は変わりません
• pip install --some_nameは、コマンドラインで指定されたパッケージのみをアップグレードしようとし、依存関係はアップグレードしません。
• pip install --some_other_nameは、古い--upgrade動作を利用できるようにします

そして、2つのオプションがあります。

• 非推奨のパスは必要ない/必要ない場合、 --some_nameは--upgradeなり、 --some_other_nameは最適と思われるものになります。
• 非推奨のパスが必要な場合、pip8の--upgradeは非推奨であることを示す警告を表示します。古い動作を維持するには、 --some_other_nameを使用するか、より安全な--some_name切り替える必要があります。指定されたパッケージとその依存関係を必要な場合にのみアップグレードします。

この2番目のケースでは、 --some_nameを--upgradeすることはできません。 したがって、 --some_nameと--some_other_name 2つの新しいオプション名を見つける必要があります

明らかな「最善の」解決策は、コマンドとしてpip installし、依存関係をアップグレードしないように--upgradeの動作を変更することであるように思われます。 唯一の本当の問題は下位互換性ですが、現在の動作に依存していると主張するユーザーがいますか？

個人的には、「それを実行し、下位互換性を確保する」という見方をする傾向があります。 現在の動作は実際にはバグであり、この変更はバグ修正であると私は主張することができます。 しかし、ある時点で、私たちは良い点に到達したと言える必要があると思います。下位互換性については、より厳密な見方をするつもりです。 私たちはまだその時点ではないと思いますが、その時点に到達するためにまだやらなければならないと感じていることをコミュニティに知らせ始める必要があるかもしれません。

インストールされているすべてのパッケージをアップグレードするには、（IMO）何らかのpip install --upgrade :all:コマンドが必要です。 ただし、これは新しい機能であるため、ここでは関係ありません。

現在の動作は、特に単一のプロジェクトではなく、実際にはプロジェクトのコレクションであるPyramidのようなプロジェクトに役立ちます。 Pyramidとそのすべての依存関係を最新バージョンにアップグレードするにpip install --upgrade-recursive Pyramid 、 pip install --upgrade Pyramid dep1 dep2 dep3 dep4を実行するか、架空のpip install --upgrade :all:を実行してさらにアップグレードする必要があることを意味します私が実際にアップグレードしたいものよりも。 ＃3194で、少なくとも1人のユーザーが、フラグを介して現在の動作を利用できるようにしたいと述べました。これは、場合によっては役立つためです。

pip install暗黙的に「最小限の」アップグレードを行うようにしない理由（下位互換性以外）はありますか？ 私は実際にインストールするだけでアップグレードは行わないようにしたい状況を把握しようとしています（IOW、まだインストールしていない場合は最新バージョンで問題ありませんが、インストールしている場合はそうではありません）インストール済み）、現在の動作が必要な場合を考え出すのに問題があります。

＃3194のような_new_ pip upgrade [--recursive]コマンドのアイデアが好きです（そしてinstall --upgradeを廃止します）

互換性を損なう、複雑な非推奨になる、またはすでにオプションが多いpip install負担がかかり、変更や複雑さが増すような選択について懸念があります。 また、私は個人的に「アップグレード」コマンドに惹かれています。このコマンドは、デフォルトでは、ディストリビューションツールの動作と同じようにアップグレードするだけです。 「インストール」インストール、および「アップグレード」アップグレード...

私は「それを実行し、下位互換性を確保する」という見方をする傾向があります

私はそうではありません:)少なくともこのようなコアロジックについては。

pipinstallが暗黙的に「最小限の」アップグレードを実行するようにします

私にとって、これは初心者のように思えますよね？ 発生する可能性のある自動ビルドの破損の数を考慮してください。 また、人々はpip installが何であるかについてのある時点で概念モデルに閉じ込められます...そしてこれは、新しいメンタルモデルのリロードを強制します。 人々はそれが好きではありません。

@qwcodeわからない、大丈夫だとは思わない。 pip upgradeの主な問題は、「インストールされているかどうかに関係なく、最新バージョンを教えてください」と言う方法を削除するか、ほぼ完全に同じことを行う2つのコマンドがあることです（ pip installおよびpip upgrade ）。 そこ短期的にはいくつかの破損することが、私は少しの実際のメンタルモデルを心配してるかもしれませんpip upgrade Iから自分のインストール命令を置き換える人にだけ普及を見ることができるので、 pip install fooにpip upgrade foo （しかし、まだインストールしていないものをアップグレードするのはなぜですか？！）

えーと、大丈夫だと思います。

インストール手順をpip install fooからpip upgrade foo置き換えて広範囲に

ロジャー、だから私はupgradeをアップグレードするだけだと思います。 「うんち」 --fill-in-missing 、私はそれに固執していないので、私がそれを持っている必要があるという意味ではありませんが、以下を参照してください。

「インストールされているかどうかに関係なく、これの最新バージョンを教えてください」

• FOOがない場合は、 pip install FOOで、最新バージョンを入手します。
• FOO場合は、 pip upgrade FOOで、最新バージョンを入手できます。

私たちは2つのケースについて話していると思います：

1. FOOがあるかどうかいるかどうかにFOOを取得したいと思います。
2. _one_コマンドで最新のFOOとBARを取得したい。 FOOインストールしましたが、 BARはインストールしていません。

これらに対してユーザーに_one_コマンドを支払う義務がありますか？ 私は人々にショートカットを与えるよりもコマンドの単純さと明快さを好みます。 しかし、ユーザーがそれを要求する場合は、 --fill-in-missingようなものが登場します。

また、私は個人的に「アップグレード」コマンドに惹かれています。このコマンドは、デフォルトでは、ディストリビューションツールの動作と同じようにアップグレードするだけです。 「インストール」インストール、および「アップグレード」アップグレード...

明確化のポイント：3つの人気のあるディストリビューションツールがどのように機能するかを確認しました。AFAICT（これはmanページに基づいていますb / c私はこれらすべてを自分で使用していません）：

• apt：
  
  
  
  • apt install <pkg>は、「アップストール」を実行します。すでにインストールされているかどうかに応じて、アップグレードまたはインストールします。
  
  
  • apt upgrade 、インストールされているすべてのパッケージをアップグレードします
  
  
  • apt upgrade <pkg>は存在しません。単一のパッケージをアップグレードする唯一の方法は、 apt install <pkg> （これは、さまざまな種類のバージョン指定子も受け入れます）
  
  
• ヤム：
  
  
  
  • yum install <pkg>は「アップストール」を実行します
  
  
  • yum upgrade 、インストールされているすべてのパッケージをアップグレードします
  
  
  • yum upgrade <pkg> 、指定されたパッケージのリストをアップグレードします。 まだインストールされていないとどうなるかわかりません。
  
  
• 自作：
  
  
  
  • brew install <pkg>は「アップストール」を実行します
  
  
  • brew upgradeすべてのパッケージをアップグレードします
  
  
  • brew upgrade <pkg> 、指定されたパッケージのリストをアップグレードします。 まだインストールされていないとどうなるかわかりません。
  
  

したがって、アップグレードにインストールを使用することは、実際にはディストリビューションツールが行うことです:-)。 私たちもそうしなければならないという意味ではありません。 単なるデータポイント。

私はFOOを持っているかどうかわかりません。私は、最新のFOOを持っているかどうかに関係なく、1つのコマンドで最新のFOOを取得したいと思っています。

これの最も明らかに説得力のあるユースケースはドキュメントにあると思います。 例： pip install -U <some package>を実行するように指示する他のスレッドでリンクしたdjangoドキュメント。 初心者には混乱しすぎるので、「 pip install <pkg>を実行する場合を除いて、 pip upgrade <pkg>実行する」ように人々に伝えたくはありませんが、 installません。アップグレードしてからpip install <pkg>を実行するように指示するだけでも混乱が生じ、古いバージョンがインストールされた状態でチュートリアルを開始し、なぜうまくいかないのかわからず、責任を問われることになります。 したがって、必ず1つの「upstall」コマンドが必要であり、ドキュメントに含めるのは単純で明白である必要があります。

比較のためのHomebrewの動作のフォローアップ：インストールされていないパッケージをインストールしようとすると、 brew upgrade失敗します。

$ brew upgrade git
Error: No such file or directory - /usr/local/Cellar/git

また、現在のbrew upgrade動作も変化しています（ここでの説明を参照してください）。 将来のリリースでは、インストールされているすべてのパッケージをアップグレードするために--allを要求するように切り替わります。

明確化のポイント

私は誰かがこれを拾うだろうと知っていました。 ：）
私はほとんど自分自身に反応しました。 私はアップグレードに焦点を合わせました。

yumアップグレード[...]まだインストールされていない場合はどうなるかわかりません。

何もしません

yum install「アップストール」を実行します

trueですが、デフォルトの動作では確認を求めるプロンプトが表示されますが、pipにはありません。

他のスレッドでリンクしたdjangoドキュメント

明確にするために、それらは実際のDjangoドキュメントではありませんでした。 Djangoのドキュメントにはpip install Djangoと書かれています（https://docs.djangoproject.com/en/1.8/topics/install/）

-U現在機能していることを考えると、人々がinstall -Uを使用する習慣を身につけることは、実際には悪いことだと思います。

リンクされた例では、 redis場合で、依存関係はないと思います。この場合は問題ありません。

人々があなたのチュートリアルを通して働き始める混乱を引き起こします
古いバージョンの場合[...]したがって、必ず1つの「upstall」コマンドが必要です。

IDK、チュートリアルが一般的にアップストールするように人々に指示する必要があることは私にはそれほど明白ではありません。 誰かがFOOのチュートリアルを行っていて、すでにFOOがインストールされている場合は、やみくもに「アップストール」するべきではないかもしれません。アップグレードすると、既存の環境が損傷する可能性があります。

チュートリアルは、かなりの数がプロジェクト自体によって作成されており、チュートリアルを見に行くときに、FOOの既存のバージョンを最初に確認することはめったにないため、チュートリアルは「アップストール」（素晴らしい用語です！）を人々に伝える必要があると思います。インストールされているのは、むしろ最新のドキュメントが何であれ、彼らは見に行く傾向があります。

また、 -U現在機能していることにも同意します。人々に無差別に使用する習慣をつけるのは悪い習慣ですが、私が考える重要なことは、提案された行動を排除することです。悪い習慣ではないと思います。 、しかしむしろ良いことです。 すでに==を使用しているはずのバージョンよりも特定のバージョンがインストールされていることを確認する必要がある場合は、フラグを追加して、デフォルトの「アップストール」をプレーンな「インストール」に戻すことができます。現在インストールされているバージョンまたは最新バージョンがインストールされています（ただし、これが実際に誰もが望んでいるシナリオを思い付くことができません）。

チュートリアルは人々に「立ち上がる」ように言うべきだと思います

繰り返しになりますが、彼らがいるこの環境は何であり、明らかにアップグレードしても問題ありませんか？ ディストリビューションシステムのPython環境の場合は、そうではありません。 それが他の環境である場合、彼らはアプリケーションのために作成しました、そしてアップストールは損害を与える可能性があります。 チュートリアル用に作成したばかりの環境であれば、アップグレードする必要はありません。

ここで重要な点は、PyPIは、ディストリビューションリポジトリのように「キュレーションされた」リポジトリではないということです。 「アップストール」はデフォルトのディストリビューションリポジトリから安全であるとかなり確信で​​きます... PyPIではそれを知りません。 すべてのアップグレードはややギャンブルです。 「インストール」は、そのままでは保守的です。

pip install ＃988を修正せずに「アップストール」のように動作させると、問題が発生することに注意してください。

AとBがインストールされ、 AはB<2が必要な場所を検討してください。 次に、新しいpip install B実行します。これにより、 Bがv3などにアップストールされます（インストールされている制約を考慮していないため）。これで、環境が破壊されました。

現在インストールされているバージョンまたは最新バージョンがインストールされていることを確認する必要がある人向けです（ただし、これが実際に誰もが望んでいるシナリオを思いつくことはできません）。

そのようなシナリオを思い付くのは簡単です。 例（残念ながら構成されていません）：現在、 statsmodelsは最新のpandas （0.17.0）によって壊れています。 私は両方のユーザーです。 たくさんのPythonバージョンがインストールされており、venvが横になっています。 したがって、Python / venvについては、まだインストールされていない場合にのみpandasをインストールしたいと思います。 もしそうなら、私もおそらくstatsmodelsを持っているでしょう、そしてそれから「upstall」はそれを壊します。

@rgommersうーん、仮想環境にパンダ0.17.0がないことは間違いありませんか？ pip install pandas!=0.17.0またはpip install pandas<0.17を実行することでおそらくそれを綴ると思いますが、それが起こる可能性があると思いますが、既にインストールしたものに依存することはまったく不合理ではないと思います。

うーん、仮想環境にパンダ0.17.0がないことは間違いありませんか？

それは私が言ったことではありません。 私はパンダ0.17.0のvenvを持っていますが、statsmodelsがないものだけです。 pip install pandas<0.17がその役割を果たしますが、それを使用することは私には思い浮かびませんでした（主に、必要がなかったため、現在のinstallコマンドはこの目的で機能します）。

とにかく、私はアップストールに賛成または反対することをあまり好みません。 あなたがそれを思い付くことができないとあなたが言ったとき、私はただ現実的なシナリオを指摘したかっただけです。

+1

この議論は結論に達することなく行き詰まっているようです。 テーブルのオプションは、現在のステータスを大幅に改善したものです。 関連するすべての長所と短所が考慮されているようです。 後方互換性と最適なAPIの相対的な重要性については意見の違いしかありません。 たぶん、pip開発者は決定を確定することを試みることができますか？

@rgommers彼らはおそらく決定をしましたか？ https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-upgrade

@rgommers彼らはおそらく決定をしましたか？ https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-upgrade

@ Liso77に感謝しますが、

上記のリンクからの@rgommersは、開発者がアップグレードコマンドを作成することを読みました。 また、インストールコマンドに「必要な場合のみ」オプションを追加する予定はありません。このオプションの用語は作成されておらず、引用符で囲まれた説明のみが使用されているためです。 したがって、10月30日のあなたの（またはdstuffの）コメントから-それは：_2です。 UXを「正しい」デフォルトのpipアップグレードに移動します..._（ところで私はこれを好みます）
あなたはこのトピックについてもっと考えていたと思いますし、私がしていることをもっと微妙に見ています。 それで、（何かを考えているなら）まだ開いているものを書いてください。 開発者がここに明確に決定を書いて、最終的にこの問題を解決するのが良いかもしれないということを意味するなら、私は同意します。

ところで。 私たちが次のようなものを持っていれば、状況ははるかに問題が少ない可能性があります

pip freeze > checkpoint.txt
pip checkout checkpoint.txt

これにより、インストールを任意の「チェックポイント」に戻すことが保証されます。 （現時点ではpip install -rは良くありません）この提案を新しい号に追加することを考えていましたが、本当に役立つ提案をもたらすには、さらに調査して分析する必要があると確信しています。 注意点はたくさんあると思いますが、私は本当に可能性を持っているのが好きです

pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="12">@bleeding_egde_branch</strong>
#or
pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="13">@stable</strong>

つまり、上記のpandasやstatsmodelsの問題のようなものを（somebody_trusted（または多くの単体テストがあるコミュニティ）の助けを借りて）解決できるということです。

（このトピックについては、https：//pypi.python.org/pypi/peepも参照してください）

@ Liso77それは簡単です：この問題に関する議論は終わっていません。 upgradeコマンドが実装された状態で待機しているPRがあります（gh-3194）が、pip開発者（少なくともqwcodeと@dstufft 、そしておそらく@xavfernandezと@pfmoore）は、それが必要かどうかを判断する必要があります、または代わりにpip installの動作を変更したい。 それが起こるまで、何も変更されません。

+1

したがって、新しいアップグレードコマンドの導入は合意されたようであり、最新の未解決の議論は、「upstall」コマンドがあるべきかどうか、ある場合は、どのメインコマンド（インストールまたはアップグレード）がそれをスイッチまたはデフォルトとして取得するかということです。 。

私の個人的な意見を投げかける：

何らかの理由で環境が最新であることをプログラムで検証したい場合に限り、アップストールのためのフェイルセーフの単一コマンドを持つことは「価値がある」と思います。 なぜ「プログラム的に」？ インタラクティブではないため、つまり、パッケージがすでに存在するか存在しないために、エラー、警告、または兄弟または姉妹コマンドを指すその他のメッセージに応答するユーザーがいないためです。
オプションで、単に文句を言うのではなく、アップグレードするかインストールするかをユーザーに尋ねるプロンプトを追加することもできます。

とはいえ、この「upstall」コマンドはどちらのコマンド（インストール/アップグレード）のデフォルトでもないため、オプションを呼び出す必要があります。 これにより、意味的に明確に定義された「インストール」および「アップグレード」動詞が明確になります。私の意見では、これらのいずれかでデフォルトでアップストールするすべてのパッケージマネージャーが間違っています。 （ yumが実行しているように見えるので）アクションを促すことは問題ありません。

これにより、 upgrade --install （ --install-missingより短い）とinstall --upgradeます。 意味的には、「最新にアップグレードする[存在しない場合はインストールする]」および「最新のものをインストールする[または既に存在する場合は最新にアップグレードする]」。 ここでの違いはあまりありません。 install --upgradeは既存のバージョンであり、認識できますが、下位互換性はありません。
ミックスのもう1つのコマンドは次のとおりです。 install-upgrade （またはupstall ？）という名前の新しいコマンド。インストールもアップグレードも「他のコマンドも実行する」オプションを取得しますが、新しいコマンドは次のように導入されます。重要な位置にある明確なセマンティクス：コマンド名自体。 これが私の好みです。

TL; DR ： upgradeとupgrade-install導入し、 install --upgrade廃止します。 明確なセマンティクスを持つすべての機能。
パッケージがすでに存在するか存在しないためにコマンドの操作が失敗した場合に、メッセージまたはオプションでコマンドのインストールとアップグレードを求めるプロンプトを追加します。

今朝、これを手動でやり直しました。 この機能リクエストに関するニュースはありますか？

+1

+1

+1

皆さん、OPで親指を立てる反応を使用して、全員の受信トレイにスパムを送信しないようにしてください。

pipはLinuxディストリビューションとは異なるQAモデルを持っているので、私はかなり確信しています。ランダムアップグレードオールコマンドは、作成中の単なる破損です。

pypiには、実際に検証およびテストされたパッケージバージョンと互換性のデータベースがありません。
そのため、QAを使用したディストリビューションとは異なり、pypiには実質的に独自のQAがなく、アップロードされたプロジェクトに完全に依存しています（品質は異なります）。

現在の一連の制約により、私はそれが祝福というよりも呪いであると確信しています
なぜディストリビューションが時代遅れなのか疑問に思う人がいたら、QAには実際の時間と労力がかかります^^

皆さん、OPで親指を立てる反応を使用して、全員の受信トレイにスパムを送信しないようにしてください。

実際には、人々からの「これが欲しい」というような応答は必要ないことに注意してください。 私たちは人々がこれを望んでいることを認識しています。不足しているのは、すでに提起されているさまざまな懸念や問題のすべてに対応する修正を開発することをいとわない人であり、PRレビュー中に必然的に発生します。

個人的には、少なくとも実装の開始点を提供する実用的なコードがない限り、この問題へのpingを控えていただければ幸いです。そして、実装まで進んで実行してください。

それ以外の場合は、可能な場合にそれを取得します。 私は個人的にこの問題に定期的に遭遇し、私はコアpip開発者なので、これに取り組むのに十分な時間があれば、私はそうすることを保証できます。 その間、「何か進歩はありますか？」 コメントは、私が趣味の時間をどのように過ごすかを指示する権利を人々が要求しているように感じるので、単に私をやる気にさせる傾向があります...

実装の開始点

それがhttps://github.com/pypa/pip/pull/3194の目的だと思いましたhttps：//github.com/pypa/pip/pull/3194を更新する必要がありますか？

@sfrieselあなたは「そしてそれを

このような提案に関する作業の50％以上が「管理」（提案の文書化、ディスカッションの管理、コンセンサスの引き出し）です。 それは必ずしも人々が好むビットではありませんが、pipと同じくらい広く使用されているコードベースでは、それは不可欠な部分です。 （はい、それは問題です。「私は趣味としてプロジェクト管理を行う」よりも「趣味としてコードを書く」と言う方がはるかに良いです:-)）

@pfmoore完全に同意します。

何年にもわたってこの問題に関連する多くの場所にまたがる提案の数と議論の量は、この問題に取り組み、短期間で明確な全体像をつかむことを非常に困難に

@RonnyPfannschmidt

pypiにはパッケージバージョンのデータベースがありません

それは本当です。 これは、（setup.pyの）実行時にパッケージによって提供される情報であり、依存関係を解決するプロセスを少し複雑にします。 さらに、現在のロジックの動作により、一部のパッケージ（scipyなどの著名なパッケージでも）は、不必要に再コンパイルしないようにインストールされている場合、依存関係（numpyなど）をリストしません。

これは、とりわけPEP 426によって解決されますが、そのPEPのステータスはわかりません。

@pfmoore

実際には、人々からの「これが欲しい」という応答は必要ないことに注意してください。

+1と言ったり、親指を立てて、これが起こるのを見たいと思っているだけです。 それは、人がこの問題に少し何かを追加し、それに貢献したように感じさせます。 ピップ開発者がやる気や説得力を必要としていると言っているのではなく、誰もがそれを言いたがっているだけです。 と...

動作するコードがない限り、この問題へのpingを控えていただければ幸いです。

親指を立てても（迷惑な）通知やメールは届きませんが、関心を示した人の数を確認することはできます。 私は誰もそれを気にするべきではないと思いますが、私は間違っている可能性があります。

親指を立てても（迷惑な）通知やメールは届きませんが、関心を示した人の数を確認することはできます。 私は誰もそれを気にするべきではないと思いますが、私は間違っている可能性があります。

ああ、そうすることで通知が回避されることに気づいていませんでした。 はい、それは良い考えです。

その次のステップは、おそらくOPか、PRの所有権を引き継ぐことをいとわない誰かが、現在のポジション、さまざまな未解決の問題、彼が提案しているもののPEPスタイルの要約を書くことです。これらのさまざまな問題の解決、および議論を再開するためのコメントの募集。

その価値については、私は以前、これと依存関係の解決、PEPスタイルについての記事を書いていました。 分割して今すぐ更新し、過去数か月で提案されたすべてのものを追加します。 アップグレードコマンド用のものは、完了したら（〜2日？）要点として投稿し、ここからリンクします。

私はまだPRの所有権を引き継ぐつもりはありません。 私は議論を再燃させ、実装可能な最終的な設計に到達するのを手伝うつもりです。 私の周りの何かが計画に行くならば、私はこれを実行に移すことができるはずですが、私はまだこれに続いて

/ cc @qwcode @dstufft @pfmoore @xavfernandez

これが私の記事へのリンクです： https ：//gist.github.com/pradyunsg/a5abeac4af90fbdc54bb266c32c0d2d8

私は最初、読者が参照できるようにさまざまな場所（〜30リンク）にリンクし、すべてのコメントスレッドをコピーしてから編集して適合させようとしました。 文書はかなり長く、私の意見はすり抜けました。 ゼロから始めてしまいました。 今は短くなっていますが、意見はありません。 私はまだそれをWIPとしてマークしました。

問題がある場合は、要点にコメントしてください。 できるだけ早く修正します。

警告：_少し_長いコメントを先に

私は既存の--upgrade振る舞いを修正するというアイデアが好きです。 下位互換性以外にこれに関する懸念はありますか？ upgradeコマンドを追加することは、インストールとアップグレードの重複が大きい​​ため、良い考えとは思えません。

FWIW、gitは--upgradeについて説明しているのと同様のことを行い、2014年のデフォルトの動作git pushしました。link

pip install --upgradeの動作を変更することに関心がある場合は、そのディスカッションのシード提案（これをP1と呼びます）を次に示します。

• 次のメジャーバージョン（9.0）以降、 pip install --upgradeは警告を出力します。

`` `
PipDeprecationWarning：pipは依存関係の最新へのアップグレードを停止します
バージョンは、デフォルトで無条件にバージョン11.0から始まります。

デフォルトの動作が変更された後も現在の動作を維持するには、
インストールコマンドは--upgrade-strategy eager渡します。

新しい動作の使用をすぐに開始するには、installコマンドを実行します
--upgrade-strategy non-eager渡します。

このメッセージを鎮めるには、。

詳細については、。
`` `

リンクされたドキュメントページには、変更とその影響の概要が記載されています。 次に、最も一般的な質問である「どうすればよいですか」に対処します。 および「どのアップグレード戦略を使用する必要がありますか？」 合理的な最も直接的な方法で。

• メッセージはクリーンアップを使用できます。
• オプションは、2つのフラグ、 --upgrade-eagerと--upgrade-non-eagerなどにすることもできます。 それがバイクシェディング、つまり最後のステップです。
  
  
  
  • 何か劇的なことが起こらない限り、バージョン11.0では、 pip install --upgrade 、依存関係をアップグレードするときに動作を非熱心に切り替えます。
  
  

編集：私は、人々が切り替えるためのより多くの時間を与えるために、変更のために3つのメジャーバージョンサイクルを置きました。 不要かもしれません。 たぶん、1つのメジャーバージョンの印刷警告と次の変更で十分ですか？

@dstufftは同様の（同じ？）アイデアを思いついた。

アップグレードコマンドが前進する場合は、そのディスカッションを再開するためのシード提案があります（必要に応じて、これをP2と呼びます）。

1. pip upgrade 、ほとんどのオプションと動作をpip installからコピーします。
2. --dry-runフラグがinstallおよびupgradeコマンドに追加され、pipが実際に実行された場合に試行する内容を出力します。
3. pip install <out_of_date_pkg>は動作を変更しません。
4. pip upgrade <not_installed_pkg>は失敗します。
5. pip upgrade <up_to_date_pkg>は何もしません。なぜ何もしなかったのかを言い、ゼロ終了コードで終了します。
6. pip upgrade <out_of_date_pkg>は、非熱心な再帰的アップグレードを実行します。
   
   
   
   • ：white_check_mark：デフォルトで非熱心な再帰的アップグレード
   
   
7. pip upgrade --eager packageは、今日のpip install --upgradeのように動作します。
   
   
   
   • ：white_check_mark：現在の動作へのオプトインを許可する
   
   
8. pip install --upgradeはRemovedInPip10Warningます。
   削除されるからです。

さらに、あなたはどう思いますか：

1. アップグレードコマンドをインタラクティブにしますか？ （apt-getのようなもの）
   
   
   
   • pip install <pkg> OSパッケージマネージャーのインストールieupstallのように動作させますか？
   
   
2. 新しいアップグレードコマンドにデフォルトで--only-binaryがありますか？
   
   
   
   • よろしければ、アップグレードコマンドに--only-sourceと--no-sourceを追加するのはどうですか？
   
   
3. パッケージの更新を「保留」するオプションを追加しますか？ IMO、これはupgrade-all要件です。
4. これらのケースを区別することは意味がありますか？つまり、異なるCLIが必要ですか？
   
   
   
   • インストール：未インストール->最新
   
   
   • アップグレード：古い->最新
   
   
   • upstall：{インストールされていない、古い}->最新
   
   

「アップストールとしてインストール」については、どちらも強く感じないので、何も提案しませんでした。 これはOSレベルのパッケージマネージャーと一貫性がありますが、大きな重大な変更になります。 それがどれほど役立つか、正確な動作とインターフェースがどのようになるかはわかりません...

多分これの上で寝ることは助けになるかもしれません。

個人的には、誰かが満足しているとしても、行動と一貫性を保つことにあまり価値はありません。 1つはPython2（安定性を受け入れる）用で、もう1つはPython 3（変更を受け入れる）用である方が良いのか悪いのか疑問に思います。

@ekevoo

1つはPython2（安定性を受け入れる）用で、もう1つはPython 3（変更を受け入れる）用である方が良いのか悪いのか疑問に思います。

1つは、それはトピックから外れています。 2つ目は、そうすると、発散が発生することです。 Python 2は（願わくば）いつかEOLに到達し、Python 3に移行する必要があり、動作の異なるツールに適応する必要があるため、現在Python2を使用している人々を遠ざけることになります。 したがって、 pipは発散を行うべきではありません（そして、IMOは行いません）。 その場合は、1つのツールにまとめておくのもよいでしょう。

OTOH、下位互換性がどれだけ許容できるかについてあなたがどう思うかはわかります...

pip 9の警告に加えて、 pip install --upgrade 、 --eager/non-eager （または他の名前）の動作を微調整するための追加オプションは私には問題ないようです。

バンプ。 みんなへの別の通知。

@pfmoore @dstufft @qwcodeうるさくなりたくないのですが、週末や来週に少し時間を取って

OK、それで私のコメント：

二つの方法についてですが、私には意見がありません。 あなたがより良いオプションであると思うものを選んで、それを実装してください、そしてそれがそこからどうなるかを見ていきます。

追加の質問について：

1. コマンドをインタラクティブにするのは-1です。 ユーザーが決定する必要のある特定の問題がない限り、「あなたが求めたもののこの結果は、あなたが明らかに気づかなかったものであり、問​​題になる可能性があります-続行しますか？」という線に沿って、それはただです無駄なノイズ。 私は一般的に「よろしいですか」というプロンプトには反対です。 追加する価値があると思われるプロンプトの具体的な提案がある場合は、詳細を含めて再度質問してください。
2. アップグレードをインストールと異なるものにするべきではないので、デフォルトでは--only-binaryになりません。 私の個人的な使用では、最初は常にpip upgrade --only-binaryが必要ですが、明示的にしたいと思います。
3. 更新を「保持する」とはどういう意味かわかりません。 どうか明らかにしてください。 しかし、一般的な回答として、最初は気にしないでください。最初のPRに「オプションの追加機能」がないようにしましょう。後で追加できます。
4. それは、この機能のさまざまな議論に関する議論の主なトピックではありませんか？ まず、 install --upgradeとupgradeの基本的な質問に影響しませんか？ その質問の解決策があったことを覚えていないので、これに対する「単純な」答えを期待していることに少し驚いていますか？ 確かに良い答えはありません。

（ちなみに、要点に簡単にアクセスできないので、要約にないコンテンツがそこにある場合は、申し訳ありません）。

PRを書くのは大変な作業だと思いますし、それを議論や質問で行き詰まらせているように見せかけるのはやる気がありますが、最終的には誰かがPRを書かなければならないと思います。そして、「これが解決策です。私は提案します-コメントはありますか？」

アップグレードをインストールと異なるものにするべきではありません[snip]おそらく最初は常にpip upgrade --only-binaryが必要ですが、明示的にしたいと思います。

おそらく常に何かが必要な場合は、デフォルトで^1にする必要があります。 しかし、 installと可能なupgradeコマンド全体で一貫性を維持することは良い考えだと思います。

更新を「保持する」とはどういう意味かわかりません。

アップグレード-すべての機能の追加について説明するまで、これを休ませておきます。

自己への注意：pipのapt-mark概念

コマンドをインタラクティブにするのは-1です。 ユーザーが決定する必要がある特定の問題がない限り

同上。

それは、この機能のさまざまな議論に関する議論の主なトピックではありませんか？

なぜ私はあなたたちがどう思うか知りたかったのです。

その質問の解決策があったことを覚えていないので、これに対する「単純な」答えを期待していることに少し驚いていますか？

私はまだ「単純な」答えを期待していません。 話し合いを通じて、できれば簡単な答えにたどり着くことを願っています。

ちなみに、要点に簡単にアクセスできないので、まとめにない内容があれば見逃してしまいました。

要約以上に、それは記事のフォローアップです。 できるだけ早くお読みください。

あなたがより良いオプションであると思うものを選んで、それを実装してください、そしてそれがそこからどうなるかを見ていきます。
[をちょきちょきと切る]
誰かが[PR]を書いて、「これが私が提案する解決策です。コメントはありますか？」と公開する必要があると思います。

「まずは何が欲しいのかを正確に把握していきましょう」と考え、それを実行していきました。

¹他人の世界を壊さない限り

アップグレードをインストールと異なるものにするべきではありません[snip]おそらく、最初は常にpip upgrade --only-binaryが必要ですが、明示的にしたいと思います。
おそらく常に何かが必要な場合は、デフォルトにする必要があります。 しかし、インストール全体と可能なアップグレードコマンド全体で一貫性を維持することは良い考えだと思います。

_everyone_がおそらく常に何かを望んでいる場合、それは（多分）デフォルトであるはずです。 しかし、私は自分の好みについてコメントしているだけでした。 正直なところ、 --only-binaryがほとんどの人が望んでいるものであるかどうかはわかりません（おそらく、長期または短期のどちらで話しているかによって異なります）。

バイナリ（ホイール）、どこでも構築できるソース（通常は純粋なPython）、およびコンパイラやその他の外部前提条件を必要とするソースの間には大きな違いがあります。 悲しいことに、pipは後者の2つを区別できず、そのため--only-binary有用性が低くなります（特にデフォルトとして）。

そして、私は「私が意味することをする」デフォルトよりもコマンド間の一貫性を大切にしています。これも私の個人的な好みかもしれません。

要約以上に、それは記事のフォローアップです。 できるだけ早くお読みください。

私はそれを読みました、それは私が気づいていなかったことをあまり追加しませんでした（私はこれに関するさまざまなスレッドをたどったので）、それで私のコメントは立っています。 しかし、それはプレーの状態の良い要約なので、それを書いてくれてありがとう。

アップグレードをインストールと異なるものにするべきではありません[snip]おそらく、最初は常にpip upgrade --only-binaryが必要ですが、明示的にしたいと思います。

おそらく常に何かが必要な場合は、デフォルトにする必要があります。 しかし、インストール全体と可能なアップグレードコマンド全体で一貫性を維持することは良い考えだと思います。

_everyone_がおそらく常に何かを望んでいる場合、それは（多分）デフォルトであるはずです。 しかし、私は自分の好みについてコメントしているだけでした。

明確化：私のコメントの「あなた」はエンドユーザー（複数形）を指しており、その特定のケースでは

アップグレード戦略に関するいくつかの考え。 もちろん、個人的な意見、これらすべて:-)

pip upgrade fooを実行するとします

1. 現在fooインストールされていない場合、エラーが発生する可能性があります。 私にとって、「インストール」と「アップグレード」は、マージしたくない2つの別個のアクティビティです。
2. 現在インストールされているものよりも新しいバージョンが利用できない場合（以下の--only-binary ）、何もすることがないという通知を期待しています。
3. それ以外の場合は、 fooが最新バージョンにアップグレードされることを期待しています。 それが私が求めたものなので、それは起こるはずです。
   
   
   
   • 制約を追加することが理にかなっているとは思いません。 1.1をインストールしているのに1.2が利用できる場合、 pip upgrade foo>1.0どういう意味ですか？ 1.1のままの場合はアップグレードではありませんが、1.2にアップグレードする場合は、 pip upgrade fooと同じです。 おそらく、 pip upgrade foo<2.0ようなものに意味を帰することができますが、IMOは非常に珍しいケースであり、複雑にする価値はありません。 したがって、 pip upgradeが（要件ではなく）パッケージ名のリストを取得すると仮定しましょう。
   
   
   • 同様に、 pip upgrade <path_to_archive/wheel>解釈方法もわかりません。 最初のインスタンスでは許可されていないと仮定しましょう。
   
   
4. pipがソースからのビルドを試みることを許可する場合としない場合があります（pipはソースからのビルドが機能するかどうかを判断できず、次の場合に別のバージョンで再試行する機能がないため、これはユーザーの決定である必要があります。ソースビルドが失敗します）。 したがって、 --only-binaryはユーザーオプションである必要があり、指定されている場合、pipは「利用可能なもの」を計算するときにソース配布を無視する必要があることを意味します。 （もちろん、デフォルトでバイナリのみを使用し、 --allow-sourceオプションを使用することもできますが、どちらの方法でも、 upgradeはこの点でinstallと一致する必要があります）。

OK、これで明示的に指定されたパッケージが処理されました。 そこに物議を醸すものがあるとは思えません（おそらく、後でまで省略すべきだと私が言う部分を除いて）。 次に、依存関係について説明します。

• 私の頭の中の主なルールは、ユーザー指定のパッケージを_実際に_アップグレードしない限り、依存関係に対して何もしてはいけないということです。 それが出発点です。 ターゲットがアップグレードされない場合は、依存関係を見ないでください。 これまで。
• 私の見解では、_すべての_依存関係は同じ方法で処理する必要があります。ユーザー指定のパッケージの直接依存関係であるか間接依存関係であるかは関係ありません。 これは物議を醸すとは思わない。
• ここでの基本的な前提は、ユーザーが依存関係のリストが何であるかを知らないということです。 結局のところ、暗黙の依存関係を持つことのポイントは、ユーザーがそれらを管理する必要がないようにすることです。 したがって、私の見解では、ユーザーが依存関係について明示的に知る必要があるソリューションには欠陥があります（特定の依存関係に関するメッセージでコマンドが失敗した場合を除きます。その場合、ユーザーはオプションで指定された依存関係を使用して再実行できますが、できるだけ多くの場合に初めて作業することを検討しているので、これは標準と見なされるべきではありません）。
• デフォルトでは、新しい制約を満たすためにアップグレードする必要がある依存関係のみをアップグレードするというアプローチが必要だと思います。 何がアップグレードされるかによって制約が変わる可能性があるため、ここには厄介な問題が潜んでいます。 しかし、その問題に対して完全な解決策を実行するか、単に「最善の努力」の解決策を試みるかはそれほど重要ではありません（制約が競合する複雑な依存関係グラフが実際に一般的であるとは思えません）。 重要な点は、必要がない限り、ユーザーがアップグレードを要求していないものはアップグレードしないという原則です。
• 「すべてを最新バージョンにアップグレードする」というフラグを立てると便利な場合があります（少なくとも下位互換性のために）。 さらに良いのは、アップグレードオプションを分析して報告するツール（おそらくpipの外部）を用意することです。 その後、ユーザーは自分で決めることができます。 しかし、私はこれらのオプションのいずれかが自分で必要になるとは思いません。
• 「熱心なアップグレード」オプションではなく、 upgrade-allコマンド（または、単一のコマンドを維持したい場合はupgrade --all必要になる可能性がはるかに高くなります。 これは、インストールされているすべてのパッケージがコマンドラインにリストされている場合、意味的にupgradeと同じである必要があります。 パッケージのブラインドアップグレードを実行すると（通常、パッケージの依存関係ツリーがわからないか、文書化されていない可能性があります）、おそらく「すべて」が必要です。 仮想環境を使用して物事を分離すると、さらにそうなります。
• --only-binary質問がここに再び表示されます。 確かに、ユーザーがメインアップグレードに--only-binaryを指定した場合、依存関係は--only-binaryを意味すると想定する必要があります。 ただし、ユーザーがメインパッケージのアップグレード時にソースのインストールを許可したとしても、依存関係のソースアップグレードの実行に伴う失敗のリスクを導入することは不合理に思えます。 したがって、ユーザーが明示的にソースを許可しない限り、依存関係をアップグレードするためのバイナリのみを検討する必要があることをお勧めします。 これは、オプション--allow-source dep1,dep2,...が必要であることを意味します。 この提案は物議を醸すと思いますが、numpyに依存するソース形式でのみ配布される純粋なPythonパッケージfooを検討してください。 numpy> = 1.10に依存するfoo1.0と、numpy> = 1.11に依存するfoo2.0があります。 ユーザーはfoo1.0を使用しており、アップグレードしたいと考えています。 彼らはnumpyを構築する手段を持っていません。 彼らはfooのソースアップグレードを許可する必要がありますが、numpy 1.11をビルドしようとして時間を無駄にしたくありません（さらに悪いことに、ビルドは機能するかもしれませんが、最適化されていないビルドを提供し、システムを破壊します）。 もちろん、 --only-binary numpy指定することもできますが、fooがnumpyに依存していることに気付かない場合もあります。

それについてです。 私にとって、要件はかなり明確です（そして、正直なところ、実装の問題を無視しても、特に物議を醸すとは思いません）。 ただし、ここでは実装が重要です（基本的に、上記で説明したように、上記では完全なSATソルバーアプローチが必要です）。 SATソルバーの実装が難しすぎるために妥協するのは、議論の余地がある場所です。

私の知る限り、実装上の課題は次のとおりです。

1. 完全なSATソルバーは難しいです。 どの代替案がより単純で、SATソルバーとどのように異なるのかを理解するのに十分な知識がありません。 （まあ、熱心なアップグレードは、私が信じているように、十分に単純です-それが私たちが現在行っていることである理由です）。 具体的には、単純な「必要のないものはアップグレードしない」という原則がアップグレードすべきではないと言っているものをアップグレードする状況が発生した場合です。
2. 私は、最も基本的な依存関係の制約以外のものについて詳しく説明しました。 バージョンの上限、または許可されたバージョンのリストに関与すると、事態は厄介になります。 しかし現実的には、そのようなケースは非常にまれである可能性があります（PyPIからの実際の依存関係情報について誰かに調査してもらいたいのですが、そうしようと試みるかもしれませんが、時間が取れないと思います）。
3. 複数のターゲット（ pip upgrade a b c ）がある場合、これを「アップグレードa」、「アップグレードb」、「アップグレードc」の3つの個別のアクションとして扱いますか、それとも3つを1つの「結合」にマージしますか。どういうわけかアクション（私はターゲットとは異なる依存関係を扱うことを提案しているので、これはダミーがa、b、cに依存し、ダミーがアップグレードされたと仮定するpip upgrade dummyと同じではないことに注意してください）。

誰かが上記のコメントや主張のいずれかで問題を起こしたいのであれば、それは素晴らしいことです。 これのほとんどは私の意見であり、私は正直に複雑な環境で作業していません-私の使用法は主にWindowsでのシステムインストールといくつかの仮想環境の維持に関するものです（したがって、バイナリインストールとソースインストールについての議論は私ですが、複雑な依存関係グラフはそれほど多くありません）。 仮定を確認できるユースケースが多ければ多いほど、良い結果が得られます。

したがって、現在、 pip installとpip install --upgrade 2つの操作がありますが、どちらも実際には誰も望んでいないことをしていると思います。

pip install場合、システムにすでにインストールされているものに基づいて最新バージョンを取得する（または取得しない）という奇妙な動作が発生します。 この種の奇妙さはピップを使いにくくしていると思います、そしてそれはあまり意味がないと思います（アップグレードしないことを気にする状況はありますが、まだ持っていない場合は最新のものをインストールしたいですそれ？）。 このコマンドがこの奇妙な多分-最新-多分-ではない動作をしているという事実が、多くの人々がpip installではなくpip install ---upgradeをプライマリコマンドとして使用しているのを見る理由だと思います。

ただし、 pip install --upgradeはそれほど良くはありませんが、一貫した動作を提供しますが、過度に熱心であり、ユーザーがpip install --upgrade関係していることに気付かない可能性がある_すべて_のアップグレードに完全に拡張されます。

ここでやるべきだと思うのは、 `pip install ... more consistent. In that I meanを作成するためのパスを見つけることです。pipinstallは、常に最新の受け入れ可能なバージョンになるはずです（指定された指定子と修飾子フラグ--only-binary ``）以前にインストールされたものに関係なく。

このコマンドにある種の--eagerまたは--recursiveまたは--upgrade-all-the-things動作を与えることは問題ないと思います。

パッケージのリストを取得するpip upgradeコマンドは、私たちがすべきことではないと思います。 このようなコマンドを追加する場合は、インストールされているすべてのものを最新バージョンにアップグレードするために使用する必要があると思います（依存関係チェーン情報、および--only-binaryなどの修飾子を考慮に入れます）。

は？ では、fooがインストールされている場合、 pip install fooは常に失敗するとは限りません。 それは私には間違っているように思えます、私はそれが単に「すでにインストールされている」と言うことを期待します。

私はpip installが「インストールまたはアップグレード」であるという考えには熱心ではありません。 明示的である方が良いです。

現在、 pip install fooは、何かがインストールされているかどうかに基づいて「失敗」することはありません。何もせず、Xがすでにインストールされていると表示されます。 私の主張は、振る舞いはあまり役に立たないということです。 「あるバージョン、これまでにインストールされたバージョンを主張する」というのは、私には役に立たないようです。 また、私がapt-getかそこらが好きだった他のパッケージマネージャーとも一致しません。

OK、動作が役に立たないことがわかります（個人的には、「すでにインストールされている」をかなり無害であると黙って受け入れています）。 しかし、アップグレードするのではなく、すでにインストールされているパッケージのインストールが失敗するのを見たいと思います。

foo 2.0がすでにインストールされている場合、 pip install foo-1.0-none-any.whlは何をすることを期待しますか？ ダウングレード？ 黙って何もしませんか？ 私は、人々が実際に覚えているとは思えない複雑なルールのセットよりも、素晴らしく単純な「すでにインストールされている」エラーを見たいと思っています。

Linuxパッケージマネージャーの経験があまりないので、pipとの類似点（またはその他）についてコメントすることはできません。 しかし、 apt-get install fooがアップグレードされるとは思わないので、アップグレードすると言えば、これも奇妙だと思うとしか答えられません。

「あるバージョン、これまでにインストールされたバージョンを主張する」というのは、私には役に立たないようです。

これについての簡単な質問：「この特定のバージョンがインストールされていることを表明する」についてはどうですか？

気にしないでください、今日私たちはその行動をしています。

@pfmoore ：

foo 2.0がすでにインストールされている場合、pip install foo-1.0-none-any.whlは何をすることを期待しますか？ ダウングレード？ 黙って何もしませんか？ 私は、人々が実際に覚えているとは思えない複雑なルールのセットよりも、素晴らしく単純な「すでにインストールされている」エラーを見たいと思っています。

ええと、期待は驚くべきことです。 この場合、ピップはダウングレードする必要があります。 ユーザーは、pipにこの特定のホイールをインストールすることを完全に明示的に言っているので、pipはその特定のホイールをインストールする必要があります。 それについて複雑なことは何もありません。 しかし、「配布パス/ファイルが明示的に指定されている」場合は＃536です。おそらく、ユーザーがパッケージインデックスに移動してfoo 2.0を見つけた「pipinstallfoo」と言った場合に何が起こるかに焦点を当てて、この議論を続ける必要があります。 foo1.0がすでにインストールされている場合。

私はここでのドナルドの立場に非常に同意します。 「 pip installは何をすべきか」という質問から始めると、名前に「インストール」と表示されているので、インストールするだけで、アップグレードしないでください（まあ、いくつかの制約がある場合を除いて）。 しかし、「ユーザーはどのような操作を望んでいますか？」という質問から始めると、最新のコマンドをインストールしたり、古いバージョンを残したりする可能性のあるコマンドは、本当に奇妙で直感に反します。 ユーザーがpip install xと入力する99％の場合、それは（a）インストールされているかどうかわからないか、インストールされていないことを知っているためであり、（b）ユーザーがインストールされていることを確認したいためです。彼らが初めてそれを使い始めようとしているので、それをインストールしてください。 （初めてでない場合は、インストールされていることを知っているので、 pip installは実行されません。）この状況では、最新バージョンを提供するのが正しい方法です。

@nchammas ：

「この特定のバージョンがインストールされていることを表明する」はどうですか？ これは、べき等のインストールコマンドがあるので、私には便利なようです。

「特定のバージョン」にはpip install x==<version>ます。

私はまた、スクリプト/プログラム的な使用のいくつかの種類のためにあると便利かもしれないと想像することができますpip require xでパッケージをインストールするのと同じ意味を持つコマンドDist-Requires: x 、それは必ずいくつかのことになり、すなわちバージョンはインストールされていますが、何についての保証はありません。 ただし、これはエンドユーザー向けではない低レベルのコマンドになります。

これらの違いを考える1つの方法： xがインストールされていない場合、 pip require xがランダムな古いバージョンをインストールしても問題ありません。 （そして、おそらく、人々にそれに対して頑強にすることを強制するべきです。）しかし、ランダムな古いバージョンをインストールするpip install xを受け入れる人は誰もいません。

（これは思考実験です。 xない環境でのプレーンなDist-Requires: xまたはpip require xは、ランダムに古いバージョンのxを選択する必要があるとは実際には主張していません。

そうですね、ユーザーがpip install xと入力するケースももう1つあると思います。これは、インストールされていることをすでに知っている場合ですが、 install常にアップグレードされるDebianスタイルの動作のシステムに慣れています。 。 明らかに、これらのユーザーもアップグレードを望んでいます:-)。

pip upgradeコマンドを追加したくありません。

pipユーザーは、すでにpipの動作にある程度の期待を抱いています。
主な問題点はpip instal --upgradeデフォルトの動作にあるので、それに焦点を当てましょう。

pip 9での警告に加えて、 pip install --upgradeの動作を微調整するための追加オプション（--eager / non-eager）に続いて、pip 10でデフォルトの動作を変更するのは簡単に思えますが、主な問題を取り除く必要があります起源とピップユーザーのピップのメンタルモデルを壊しません。

ええ、私は間違いなく「ユーザーが何をしたいのか」から「Xコマンドが何をすべきか」からこれにアプローチしようとしています。 次に、ユーザーがやりたいと思うこの高レベルの操作を実行し、それを単一の名前付きコマンドにマップしようとしています（pip install-the-latest-version``はあまりユーザーフレンドリーではありません） 。

これは明らかにすべて非常にあいまいですが、99％の時間はpip install -U <whatever>あると言えます。これは、現在利用可能なものを考えると、インストーラーに期待するものと最もよく一致するためです。 また、さまざまな自動化スクリプトで、 pip install -Uを使用している人もいます。 これは、npmのように、他の一般的な言語のパッケージマネージャーがデフォルトで行うことでもあります。 -Uを使用していない人がいる場合、それは再帰的な性質によるものであり、最新バージョンのインストールを望まないためではありません。

pipユーザーは、すでにpipの動作にある程度の期待を抱いています。

ただし、TBHは、ユーザーとしてのpipについての主な期待は、呼び出しの約50％で、驚くべき、明らかに間違った処理を実行することです。 そして、私だけではありません。たとえば、先週のpyconでの@glyphの講演を参照してください。彼は、すべてのデフォルトが壊れており、unbreak-meフラグが必要なことを除いて、pipが優れていることを確認しました。 これはpip開発者の批判ではありません。私はあなた/私たち全員が複雑な一連の制約の下で作業していることを理解しています。ピップにはたくさんのピースがあり、それらの多くは大丈夫です！ しかし、popのデフォルトの全体的な状態を考えると、「pipは常にXを実行しているので、pipは常にXを実行する必要がある」という形式の引数には、私は_本当に_確信していません。 アップグレードを拒否するためにpipinstallについて議論したいのであれば、それはすばらしいことですが、慣性だけでなく、実際のメリットについても議論したいと思います。

ええ、私は確かにここで@glyphに同意します。 私たちは多くの悪いデフォルトの振る舞いを持っています、そして前進することの一部は私たちがそれらを取り除きそしてそれらの壊れた変化に対処して物事をより良いデフォルトに向けて動かす方法を理解する必要があると思います。

この特定の変更はそれらの1つではないかもしれませんが、私はそう思います。

ええ、私は間違いなく「ユーザーが何をしたいのか」から「Xコマンドが何をすべきか」からこれにアプローチしようとしています。 次に、ユーザーがやりたいと思うこの高レベルの操作を実行し、それを単一の名前付きコマンドにマップしようとしています（pip install-the-latest-version``はあまりユーザーフレンドリーではありません） 。

わかった。 私がこれについて（ある程度）確信していると自分自身を数えることをいとわないとします。 ただし、これが正しいことであると想定した場合、依存関係についてはどうでしょうか。 私は、「ソースからnumpyをインストールしようとする」ことは、ほとんどの場合、望まれていることではないと100％確信しています。 したがって、ユーザーが明示的にnumpyに言及しない限り、ホイールからnumpyをインストールするだけです。 それを今のところ与えられたものとしてとらえ、それから私たちが前に説明した状況を持っていると仮定します。

• ユーザーにはfoo1.0とnumpy1.10がインストールされており、foo1.0はnumpy> = 1.10に依存します
• PyPIにはfoo2.0があり、numpy> = 1.11に依存します。 ゴツゴツした1.11ホイールはありません。

pip install fooは何をしますか？ インストールが機能しているので、おそらくユーザーを1.0のままにしますか？ しかし、成功する必要がありますか（fooがインストールされているため）、失敗する必要がありますか（最新バージョンをインストールできなかったため）？ 前者の場合、ユーザーは自分のシステムが古くなっていることをどのようにして見つけますか？ 後者の場合、ユーザーは「fooが存在することを確認したい」とどのように言いますか？ OK、ユーザーはpip list --outdated実行でき、foo 2.0が存在することを確認し、 pip install foo （ところで、それはまだ私にはまったく奇妙に思えます、私はfooを持っていますが、新しいバージョンがあることを知っています。私はpipinstallを実行します???気にしないでください...）そして成功しますが、1.0はインストールされたままですか？

私が2つのコマンドを好む理由の1つは、ユーザーの意図が完全に明確であり、ユーザーの期待を知っているため、このようなエッジケースを正しく処理できることです。

apt-getに慣れている場合は、これはすべて明らかです。 しかし、私のようにそうでない人には、はっきりとは言えません。

アップグレードを拒否するためにpipinstallについて議論したいのであれば、それはすばらしいことですが、慣性だけでなく、実際のメリットについても議論したいと思います。

私の議論は、暗黙的ではなく明示的であることに基づいています。 「私たちはいつもこのようにしてきた」ということについては間違いなく_ではありません_。 おそらくaptユーザーが「おそらくアップグレード」を意味する「インストール」に慣れているという考えに問題はありません。 他のユーザーがそうなるかどうかは本当にわかりません。

ある考え-aptには「パッケージはすでに存在します-アップグレード」がありますか？ 促す？ install-as-upgradeは、「install-or-ask-if-I-should-upgrade」の場合はそれほど驚くことではないと想像できます...もちろん、pipは現時点ではそのようにインタラクティブに動作しませんが、明らかにそうすることはオプションです。

これは興味深い質問です。他のパッケージマネージャーは、ほとんどの場合、バイナリパッケージをまったく持っていないため、ソースごとに_常に_であるか、バイナリパッケージのみを処理するため、_常に_バイナリであるため、これを回避します。 私たちはその間にある種の奇妙な状況にあり、それが困難になっています。

それを考えると、今のところデフォルトでnumpy 1.11ソースパッケージをプルダウンしてインストールする必要があると思いますが、 --only-binaryが指定されている場合は、架空のリゾルバー（SATがどうしても必要です）またはバックトラッキングなど）は、 foo-2.0が解決可能なインストールではないことを確認し、 foo-1.0インストールにフォールバックします。 これは、特にコンパイルが_はるかに難しいWindowsのユーザーにとっては、優れたデフォルトではありませんが、今日の現実を反映していると思います。

そうは言っても、私が本当にやりたいことの1つは、pipの動作を再び変更できる世界に向けて物事を推し進め、デフォルトでバイナリのみになり、ソースリリースにオプトインが必要になるようにすることですが、私は私たちがまだそれができる場所にいるとは思わないでください。

@pfmoore ：バイナリインストールとソースインストールの問題はやや直交していると思いますか？ 専用のpip upgradeコマンドでもまったく同じ質問が発生するように思われるので、対処する必要のある実際の問題ですが、アップグレードとインストールを分割すると、問題が単純化されるのではなく、移動するだけですか？ また、numpyの特定のケースでは、サポートすることに関心のある基本的にすべてのプラットフォーム用のホイールを出荷しています:-)。

しかし、これらの問題をpip install foo処理することを提案する方法は次のとおりです（具体的には、このコマンド- pip install foo==whateverまたはpip install ./foo-*.whlまたはpip install barについては話していません。ここでbarはRequires-Dist: foo ）：

1）インデックスをクエリして、 fooの最新の候補バージョンを見つけます。 これを$LATESTと呼びます。 候補バージョンが存在しない場合は、エラーになります。

2） $LATESTがすでにインストールされている場合は、正常に終了します。

3）現在の環境にインストールできる$LATESTディストリビューションがあるかどうかを確認します。 （存在しない理由の例：ホイールのみがあり、sdistはなく、ホイールは現在の環境と一致しません。一致するホイールはなく、sdistはありますが、ユーザーは--binary-only :all:を通過し

4） $LATEST実行可能な配布がない場合：警告を発行して、新しいバージョンは利用可能であるが環境には利用できないことをユーザーに通知します。理想的には、実際に実行する場合に何をする必要があるかについてのヒントを示します。新しいバージョンが必要です（たとえば、「ipython 6.0.1は利用可能ですが、python> = 3.4が必要で、python2.7があります-pythonのアップグレードを検討してください」または「numpy1.12は利用可能ですが、ppc64のバイナリはなく、ソースからのビルドを無効にしました- --allow-source numpy検討してください）。次に、候補バージョンのリストから$LATESTを削除し、手順1に進みます。

5） $LATEST _does_に実行可能なディストリビューションがある場合は、このディストリビューションのインストールを試みてください。

6）インストールが失敗した場合（たとえば、b / cはsdistであり、コンパイラはありません）、エラーが発生します。 それ以外の場合は、正常に終了します。

@njsmithバイナリのみはある程度直交しており、同意されていますが、IMOが「ユーザーが期待することを実行する」コマンドを設計しようとしている場合は、これを同時に正しく行うことが重要です。

@dstufft 「ユーザーが--binary-onlyを私の前の壮大な投稿の例で説明されていない限り、numpyをインストールする-（1）fooはソース形式でのみ利用可能であると言い、（2）ユーザーはそうではないかもしれない（そして実際にそうする必要はないはずです）fooがnumpyに依存していることを知っていると、ユーザーは--only-binary :all:と言うことができず、コンパイルが（長い）失敗した後まで--only-binary numpyが必要だとはわかりません。 （おそらくさらに悪いことに）コンパイルが成功すると、ユーザーに最適化されていないnumpyが残ります（最近では、numpyはWindowsでそのままコンパイルされますが、最適化されていないビルドが提供されます）。

長期的にはデフォルトでバイナリのみにする必要があることに完全に同意しますが、まだその近くにはありません（少なくとも、ほとんどすべての純粋なPythonパッケージがホイールとして利用可能であることを意味するはずです）。

@pradyunsgご覧のとおり、ここには未解決の問題がまだたくさんあります。 あなたはまだこれを前進させることに興味がありますか？ それが再び失速するのであれば、私は別の長い議論を開始するのは気が進まない...

@pradyunsgご覧のとおり、ここには未解決の問題がまだたくさんあります。 あなたはまだこれを前進させることに興味がありますか？ それが再び失速するのであれば、私は別の長い議論を開始するのは気が進まない...

あると思っていました。 私はこれを前進させることに興味があります。 これをやろう！ ：笑顔：

_user_がpipに実行させたいことをすべてリストにまとめてから、pipコマンド（オプション/デフォルトを使用）ですべて（または十分な量）が解決されるまで、またはで処理できるようになるまで、それぞれの解決策を提案することをお勧めします。 "何もしない"。

まず始めに、最も可能性の高い不完全なリストを次に示します。

1. ユーザーがまだインストールされていないパッケージをインストールしたいと考えています。
2. ユーザーが、すでにインストールされているパッケージをインストールしようとしました。
3. ユーザーは、インストールされているパッケージをアップグレードしたいと考えています。
4. ユーザーが、インストールされていないパッケージをアップグレードしようとしました。
5. ユーザーは、パッケージが既にインストールされているかどうかに関係なく、最新バージョンのパッケージがインストールされていることを確認したいと考えています。
6. ユーザーは通常、すべての依存関係をアップグレードすることを望まず、代わりにそれらを満足させるだけにします。
7. ユーザーはパッケージをアップグレード/インストールしたいが、ソースからビルドしたくない（パッケージもその依存関係も）。 おそらくより可能性が高い：
8. ユーザーは、ソースからアップグレード/インストールする用意があります。

ユーザーとしてのこれに対する私の個人的な提案：

1）＆7） pip install fooは、（依存関係を考慮して）利用可能な最新バージョンに解決し、インストールを試みる必要があります。 アルゴリズムは@njsmithのです。
2） pip install foo →fooがすでにインストールされているという警告を表示し、 pip upgrade foo使用を提案します
3）＆7） pip upgrade fooは、 @ njsmithのアルゴリズムに従って、利用可能な最新バージョンのfooをインストールしようとします。 プラットフォームで利用できないために新しいバージョンをインストールできず、sdistがない場合、またはユーザーがソースからビルドしたくない場合は、そのことを示してください。 どちらの場合も成功し、インストール自体が失敗した場合にのみ失敗します。
4）パッケージがインストールされていない場合、 pip upgrade foo失敗します。
5） pip install-uprade fooまたはpip install foo --ensure-latestまたはpip install foo --upgrade （基本的に、熱心でないことを除いて現在と同じ）。
7）すべての操作は熱心ではなく、 --eagerフラグを使用して、 install --upgradeの古い機能を取得できます。 依存関係がまだインストールされていない場合は、最新のものをインストールしてください。 すでに満足している場合は、何もしません。 それが満たされない場合は、最新のまだ満足しているバージョンをインストールします（上限の要件の場合）。
8）fooが非バイナリのnumpyリリースに依存している場合pip upgrade foo --allow-source numpy 、 pip upgrade foo --allow-sourceまたはpip upgrade foo --allow-source numpy 。 編集：これが適用できるかどうかはわかりません。以下のコメントを参照してください。

リストを拡張して、独自の提案を投稿してください。

@pfmoore代替案が何であるか

@dstufft私の提案は、明示的に名前が付けられたパッケージのソースを許可することでしたが、デフォルトでは依存関係のバイナリのみになっています。 そうすれば、ユーザーは「驚きの」ビルド手順を取得できません。 これは確かに妥協案ですが、現時点で私が（しなければならない）手動で行っていることを反映しています。

@FichteFoll何よりも、私の主なユースケースは「すべてアップグレード」機能です。 現在インストールされているものをすべて探し、利用可能な新しいバージョンがある場合は、それらをアップグレードします。

私がインストールしたパッケージには、通常、「> =」以外の依存関係はありません（ほとんどの場合、依存関係もありません）。したがって、ここでは複雑なことは何もありません。 最新バージョンを入手するだけです。 私の最大の制限は、ビルドできないパッケージ（numpy、scipy、lxml、pyyaml、matplotlib、pyqt）があるため、それらのバイナリのみが必要なことです。 私はおそらく--only-binary <these>をpip.iniに入れることができます（または少なくとも私ができることを願っています...）

二次：パッケージXXX（最新バージョン）と、まだ持っていない依存関係をインストールします。 新しいパッケージの制約を満たしている場合は、すでに持っている依存関係をアップグレードしないでください。 私は現在XXXを持っていないことを常に知っています。

三次：私（私が知っている）がインストールした単一のパッケージXXXをアップグレードします。 依存関係の制約を維持する必要がない限り、他のパッケージを変更しないでください（それでも理論的です-私は実際にこの状況に遭遇したことがないので、私にとって最良の解決策はわかりません）。 私の意図は常に「最新バージョンへのアップグレード」です。 これにより、すでにインストールされているパッケージの依存関係が壊れるような状況に遭遇したことはありません。 もしそうなら、私は最新バージョン（そしてその理由）を入手していないという警告に加えて、許容できる最新バージョンへのアップグレードをしたいと思います。 私の考えでは、この状況は現在pip install -U変換されますが、依存関係の動作は私が望むものではありません。 ただし、これを行う主な理由は、適切な「upgrade all」が現在不足しているためです（または、新しい「upgradeall」コマンドが希望どおりに機能しなかった場合に対処するため）。

依存関係と制約に関するすべての議論は、私の経験では、ほぼ完全に理論的です。 現在、システムPythonに160個のパッケージがインストールされています（科学、データ分析、Web、および一般的なプログラミングモジュールの組み合わせ）。 それらの100は要件がありません。 残りの部分については、パッケージのリストよりも複雑なものはありません。バージョンの制約や、 Requires: six, dask, pillow, networkxよりも複雑なものはありません。 依存関係の最長リストには9つの項目がありました。

@pfmooreそれは多くのことを壊すつもりではないですか？ 非常に人気のあるパッケージであることがわかっていることを頭の中で思いつくことができるものの簡単なリストは、次のものに依存します。

• SQLAlchemy（オプションでコンパイラが必要です。そうでない場合は純粋なPythonを使用します）。
• PyYAML（オプションでコンパイラが必要です。そうでない場合は純粋なPythonを使用します）。
• Markupsafe（オプションでコンパイラが必要です。そうでない場合は純粋なPythonを使用します）。
• PyCrypto（常にコンパイラが必要です）
• pycparser（コンパイラは必要ありません）
• httplib2（コンパイラは必要ありません）
• anyjson（コンパイラは必要ありません）
• zope.interface（オプションでコンパイラが必要です。そうでない場合はPure Pythonを使用します）。
• docopt（コンパイラは必要ありません）
• Mako（コンパイラは必要ありません）
• その危険（コンパイラを必要としない）
• amqp（コンパイラは必要ありません）
• Ordereddict（コンパイラは必要ありません）

など、最も人気のあるパッケージの長いリストと、それらにホイールがあるかどうかはhttp://pythonwheels.com/で確認できます。

@pfmoore

現在インストールされているものをすべて探し、利用可能な新しいバージョンがある場合は、それらをアップグレードします。

このコマンドは、私が現在これに使用しているSOの質問から少し前に入手しました。 これは最適ではありませんが、1つを除いてほとんどのパッケージで機能します。 （私はWindowsを使用しているため、 pyランチャーを使用します。）

pip list -o | cut -d " " -f 1 | xargs -n1 py -m pip install -U

さて、これに関して私が抱えている問題の1つは、次の要件を持つflake8パッケージです。

Requires-Dist: pyflakes (>=0.8.1,<1.1)
Requires-Dist: pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2)
Requires-Dist: mccabe (>=0.2.1,<0.5)

特にpyflakesは問題です。これは、新しいバージョンが利用可能であり、上記のコマンドで更新され、flake8が（バージョンをチェックするため）何も実行できなくなるためです。
したがって、これは確かに考慮する必要があるものであり、適切なアップグレード（要件を破ることなく）すべての機能が必要です。

@dstufftなぜですか？ fooがpyyamlに依存していて、fooをアップグレードするように依頼した場合、pyyamlはアップグレードされません（新しいバイナリはありません）が、元のpyyamlがまだ存在するため、fooはアップグレードできます。

新しい依存関係の場合（または依存関係が常に存在するとは限らないインストールの場合）、インストールする必要があるため、バイナリがない場合はソースを使用します。 私は個人的に「ソース付きの新しいバージョンよりもバイナリ付きの古いバージョンを選択する」ことを検討しますが、それは私たちが準備ができていないことに同意する--binary-onlyデフォルトに危険なほど近づいています。

うーん、多分私が持っている問題は実際には--only-binaryオプションにありますが、これは粗すぎます。 --prefer-binaryオプションがある場合、「バイナリのみを使用します。ただし、候補がない場合は、ソースの許可を再試行します」と述べた場合、アップグレードを熱心に行うと破損する可能性があるという懸念の多くが疑われます。軽減される可能性があります。 これは、 @ njsmithが示唆しているように、私が焦点を当てているバイナリ/ソースの区別がこのチケットに直交している可能性があることを意味します（ただし、 --only-binaryよりも優れたものがなければ、私の要件に対する満足のいく解決策はありません。

特にpyflakesは問題です

OK、それは私が持っている状況ではありません（私が言うように、私は複雑にインストールされた依存関係を持つものは何もありません）。 「すべてアップグレード」を改良して「破損しない最新バージョン」にアップグレードすることに問題はありませんが、正しい解決策を見つけるには「SATソルバー」アプローチが必要なAIUIです。 ただし、これは実装上の問題です。設計では常に正しい結果が得られるはずです。

@pfmooreこのチケットの結果に関係なく、 --prefer-binaryフラグが適切なオプションになると思います。 それがなければインストールされていたであろう最新バージョンをインストールしなくなったときに警告がバンドルされている可能性があります。

@FicheFoll ：第一原理からUI全体を再構築しようとしても、それほど生産的ではないと思います。 この特定の問題で話題になっている問題の比較的明確に定義された部分があり、一度にすべてに範囲を拡大しようとすると、それは再び行き詰まります。

そのトピックでは、私たちが異なる重要な場所は次のように見えます。ユーザーが、 pip install fooはアンインストールからインストールに移行するためだけのものであり、 fooを理解しているというメンタルモデルを持っているとします。 pip install foo _と入力しないと断言します。 したがって、 fooがすでにインストールされているときに一部のユーザーがpip install fooと入力すると、そのメンタルモデルはあなたの（2）とは異なると結論付けることができます。 _どちらか_最初の部分は間違っています： fooがインストールされていることを知っており、他の人気のあるパッケージマネージャーのようにpipがアップグレードされることを期待しています_または_、2番目の部分は間違っています： fooがインストールされていることに気づいていません、その場合、彼らはinstallが最新バージョンを残すことを期待しています（パッケージがインストールされていないときにインストールが行われ、このパッケージがインストールされていないと彼らが考えるため）。

ちなみに、 pip install ...がアンインストールされた状態からインストールされた状態になり、 pip upgrade ...がインストールされた状態から新しいものに移行するのが嫌いな理由の1つは、ユーザーを見つけたからです。かなり不器用な経験。 あなたが何をしたいのかを知っているソフトウェアですが、その代わりに、別のコマンドを呼び出すように指示するのは、信じられないほどイライラします。

$ pip install foobar
I'm sorry, but foobar is already installed, you want to run ``pip upgrade foobar``
$ pip upgrade foobar
...

技術的には「正しい」とはいえ、私を苛立たせる以外は何もしません。

その逆に、「OK、 pip install foobarすでにfoobarインストールされている場合は、インストールされていないように動作します。 pip upgrade foobarを実行すると、すでにインストールされているように動作しますが、基本的に同じことを行う2つのコマンドになりますが、処理方法にわずかな違いがあります。これは、 --options単一のコマンドとして属していることを示しています。エッジケースに対処するための--flagsについていくつかの選択を行うためのコストを支払う必要があります。

わかった。 私が確信していると考えてください。 私はいくつかの調査を行いましたが、私が（おそらく:-)）精通しているWindowsインストーラーでさえ、アップグレードとしてインストールを実行します（VirtualBoxのようなものをインストールすると、「以前のバージョンが既にインストールされていますか？アップグレードしたいですか？」）Powershellにはinstall-packageがあり、具体的なことは何も言われていませんが、upgrade-packageはありません。 などですから、「インストール」コマンドを1つだけ持つのが一般的だと思います。

もちろん、これは、他の誰かが議論したくない限り、技術的には、このPRは単に「実装されない」として閉じることができることを意味します。 しかし、インストールコマンドをどのように改造したいかを議論するのに最適な場所だと思います。

OTOH、多分私たちはこれを拒否されたとして閉じます、そして誰かがインストールコマンドを修正するべきであると彼らが提案する方法の具体的な提案で新しい問題を開きます。 それは少なくとも議論のより明確な出発点を提供するかもしれません。

質問。 ここや他の場所でのすべての提案から、誰かが完全に提案された行動をまとめることができる時点にいると誰かが思っていますか？ 依存関係の処理方法、制約（およびそれらが競合する場合）、バイナリとソース、「すべてアップグレード」シナリオのサポート方法などをカバーしていますか？ 私の個人的な感想は、その決定を下す誰かが必要であり、議論に基準点を与えるか、あるいは詳細を永遠に議論することができるということです。 私はおそらくそれを行うことができますが、私が提案するものを実装することはできそうにありません（たとえば、SATソルバーAIUIを意味する「最適な依存関係解決」アプローチを提案します）。 ですから、彼らの提案を実行することをいとわない人にとっては、ステップアップする（そして避けられない議論とバイクシェディングに対処する:-)）方が良いでしょう。

ここでのポイントの影響についてはまだ心配していますが、実装の可能性が実際に出るまで、それらについて議論するエネルギーがあるかどうかはわかりません。

@dstufftの最新のhttps://github.com/pypa/pip/issues/59#issuecomment-224341218に完全に同意し
そのため、（もう一度） --eager / --non-eagerオプションの単純なソリューションを提唱します。

述べたように、私も（私たちは、単一のために行く、の@dstufftとコメントを同意installコマンドなしupdateコマンド）。

ただし、 --eager / --non-eagerが何を意味するのかわかりません。 --non-eagerは、更新する必要のないものをアップグレードしないことを意味すると思います（ユーザーが明示的に指定したか、新しい依存関係のセットを満たすには古すぎるため）。 --eagerは、必要かどうかにかかわらず、すべての依存関係を可能な限り最新のバージョンにアップグレードすることを意味しますか？ どちらがデフォルトになりますか？ （私は--non-eagerについて議論したいと思います）

そして質問-これは科学的なパッケージがそれらの依存関係を正しく宣言することを奨励しますか？ それは重要な考慮事項でなければなりません。

バイクシェッドポイント。 オプション名--eagerと--non-eagerはかなり直感的ではありません。 もっと良い言葉が必要だと思います。 たぶん--upgrade-dependenciesような明示的なものです。

このPRは、 upgrade-allコマンドも提案します。これは、私にとって重要なユースケースです。 あなたは私たちがその命令を拒否すると言っているのですか、それとも単にあなたがそれについて意見を持っていないということですか？

--eagerと-non-eager意味についての私の理解は、 @ pfmooreが今言ったことと一致し（依存関係が必要な場合のみであるか、常にインストールされているかどうか）、 --non-eager必要であることに同意しますデフォルト。 私はまた、名前がちょっと不器用であることに同意しますが、口いっぱいではないより良い解決策はありません。 たぶん--[no-]recursiveか何か、わかりません。

upgrade-allコマンドのようなものは良い追加かもしれないと思います（それが何かのバージョン指定子に違反しないことを確認した限り）。 私はおそらくこれをupgradeと呼んで、動作を制限するための引数を取らないようにします。

tl; dr
upgrade-all-packages議論-ここにとどまります。
優先バイナリに関するディスカッション-＃3785まで
install-as-upgradeの説明-＃3786まで

--prefer-binaryオプションがある場合は、「候補がない場合を除き、バイナリのみを使用します。候補がない場合は、ソースの許可を再試行してください」と表示されます。

これは良い考えです。 この問題に関連している間、私はそれがそれ自身の問題に値すると思います。 （ @dstufftのコメントは、それを追求することに興味があると私に思わせます）。 これについてさらに議論するために、私は自由に＃3785を開きました。

--eagerと-non-eagerの意味についての私の理解は、@ pfmooreが今言ったことと一致し

熱心なアップグレードは、すべての（サブ）依存関係の最新の許可されたバージョンをインストールします非熱心なアップグレードは、パッケージの要件を満たさなくなった場合にのみをアップグレードします。

オプション名--eagerと--non-eagerはかなり直感的ではありません。

同意します。 私は、振る舞いを単一の旗の後ろに置くという考えが好きです。
--upgrade-strategy=eager/non-eager

それも一口ですが、意図をより明確に伝えます。 冗長すぎますか？ 多分。

自転車の脱落は、セマンティクスを完成させた後に行うのが最適だと思います。

ここや他の場所でのすべての提案から、誰かが完全に提案された行動をまとめることができる時点にいると誰かが思っていますか？

そう思います。 少なくとも、私たちが同意するいくつかの基本的な事実を確立する必要があります。 私はこれにいます。

OTOH、多分私たちはこれを拒否されたとして閉じます、そして誰かがインストールコマンドを修正するべきであると彼らが提案する方法の具体的な提案で新しい問題を開きます。 それは少なくとも議論のより明確な出発点を提供するかもしれません。

upgrade-all提案しているので、今のところこの問題は開いたままにしておくべきだと思います。 アップグレードが行われていないことはすでにお気づきです。 install-as-upgradeコマンドについてさらに説明するために、＃3786を開きました。

ここでのポイントの影響についてはまだ心配していますが、実装の可能性が実際に出るまで、それらについて議論するエネルギーがあるかどうかはわかりません。

私はこれを実装までずっと進めていきたいと思っています。 私は間違いなく、これについてコンセンサスを得るために他のみんなの努力を無駄にしたくありません。

「世界をアップグレードする」コマンドがあれば本当にいいと誰もが同意していると思いますが、リゾルバーの作業が着陸するのを待つ間、IIUCはブロックされます。 その間に、私は@pradyunsgのその議論のための新しい専用の問題に、単一パッケージのアップグレードに関する投稿しました。

「世界をアップグレードする」コマンドがあれば本当にいいと誰もが同意していると思いますが、リゾルバーの作業が着陸するのを待つ間、IIUCはブロックされます。

実際、この問題は＃988によって適切にブロックされています。 2つの問題をクロスリンクするための問題番号に言及します。

忘れそうだった...

更新を「保持する」とはどういう意味かわかりません。 どうか明らかにしてください。

この問題はアップグレード専用ですので、明確にする必要があります。

upgrade-allを実行するときに、特定のパッケージのアップグレードを防ぐことが役立つ場合があります。 私が念頭に置いている具体的なものは... pkgがインストールされていて、潜在的な新しいバージョンを再構成することを気にしたくない場合は、実行時にpipがその特定のパッケージをアップグレードしないようにします。世界'。 基本的に、私はpkgのアップグレードを控えています。

アップグレードを差し控えるためにパッケージのコンマ区切りリストを取得するフラグは問題ありません。

SATソルバーが登場したら、これを追加するのは簡単です。 これは、IIUCのいくつかの追加条項です。 （はい、SATソルバーもブラッシュアップしています）

これが一般的なものなのか、誰かが望んでいるものなのかはわかりません。 しかし、これは私の頭の中で起こったとは思いません。 誰かがどこかのスレッドでそれについて言及したに違いありません。

ああ、なるほど。 それは理にかなっており、望むのは合理的なことのようです。

クイックリクエスト：アップグレードコマンドが実行されないという小さなメモを説明に追加していただけませんか？ おそらくあなたが望むなら、それがなぜそうなのかについての小さな要約を書いてください。

_{_眠りにつく_}

aptが持っている2つの素晴らしい機能（そしてdnfのような他の成熟したシステムパッケージマネージャーも同様の機能を持っていると思います）：

• パッケージを「保留」としてマークします。これは、パッケージに付加された永続的なフラグであり、upgrade-the-worldコマンドによってスキップされます。 多くの場合、ローカルでダウングレードまたはパッチを適用する必要のあるパッケージに設定されます。
• どのパッケージがユーザーによって明示的に要求されたか、どのパッケージが依存関係の制約を満たすために暗黙的にインストールされたかを追跡します。 後者は、依存しなくなった場合、アップグレード・ザ・ワールドによって削除できます。

これらは両方とも、npmやcargoなどの最近のプロジェクト環境パッケージマネージャーが行う特殊なケースと見なすことができ、人間指向の「要件」ファイルと完全に指定された「ロック」ファイルを区別します。 明示的に保持されたパッケージは、人間が指定したバージョン制約を持つパッケージのようなものであり、明示的にインストールされたパッケージは、人間が編集可能なファイルにリストされているパッケージです。

同上。 「世界をアップグレードする」を追加する場合は、パッケージにマークを付ける機能を追加して（ held / user-installedなど）、情報を追加して、アップグレード。 私はこれを要件として見ていますが、持っているのは良いことではありません。

私は実際にCargoで使用されているテクニックが好きです。 何らかの形式のmeta-data-hidden-behind-a-cli-commandではなくファイルを使用すると、把握、管理がはるかに簡単になり、再現可能な環境を作成することもできます。

pyproject.lock形を見たら、私は実際に幸せになるでしょう...

200番目のコメント。 わお。 ：スマイリー：

話したパッケージの「マーキング」については、＃654への参照を追加します。

貨物が何をしているのか説明してもらえますか？ pyproject.lockファイルがユーザーのマシンのどこに保存されているのを確認できますか？

RustのCargoのロックファイルはプロジェクトルートに保存され、現在インストールされている依存関係のバージョンを記録します。 このファイルをgitにコミットすると、依存関係のバージョンの一貫したセットを他の開発者やCIと共有できます。 PHPのComposerには、同様のロックファイルComposer.lockがあります。

私はいつも、pipの「pipfreeze」と「pipinstall -r」は同じようなことをすることを意図していると思っていましたが、ロックファイル形式が人間によって簡単に読み書きできるのは残念でした。 Requirements.txtは元々ロックファイルとして考えられていませんでしたか？

@triplepoint説明ありがとうございます。 それは確かに要件ファイルのように聞こえます。 ただし、要件ファイルはオプションで、バージョンベースでプロジェクトごとです。 マーキング（私が理解しているように）は環境（virtualenvまたはシステムインストール）ごとに行う必要があり、単に「パッケージXを自動アップグレードしないでください」と言う必要があります（ただし、ユーザーがそのパッケージの名前によるアップグレードを明示的に要求する場合は、手動アップグレードを許可してください）。

upgrade-allと「アップグレード動作」に関する議論を解きほぐすために、 upgrade-all最初の実装にSATソルバーが不要であるという後者のリストの議論における@rbtcollinsと@ncoghlanからのコメントを次に示します。 upgrade-all ：

ロバート：

チケットのコンセンサスはブロックされていることだと思いますが、私はしません
実際に同意します。

はい、完全なリゾルバーがないと_正しく_できませんが、できます
何もないよりもはるかに良い近似（ただ狭い
すべての要件にわたって指定された指定子）。 それは実際には
推定される良いバージョンのセットを扱っている場合は合理的です
（どのインストールは処理しません）。

ニック：

「yumupgrade」は、適切なSATソルバーがなくても何年も十分に機能し、通常のLinuxインストールのパッケージセットは、通常の仮想環境のパッケージセットよりもはるかに大きくなります（ただし、ディストリビューションは、最初の要件で競合する要件が発生する可能性を減らします）場所）。

とは言うものの、pip-compileを再実行してからpip-syncを実行することは、すでにupgrade-all操作（venvの破棄と再作成と同様）と機能的に同等であるため、一括アップグレードのサポートに関する質問を結合する必要はないことに同意します。名前付きコンポーネントのアップグレードの動作を変更するベースラインピップ。

IMO、 pip upgrade-allは、さまざまな「アップグレード機能」の議論の中で、これまでで最も重要な提案です。 「すべてアップグレード」することで、システムを最新の状態に保つための明白な方法が得られ、熱心でない更新について質問をして、古いレベルのものをはるかに少なくし、現在存在するギャップを埋めることができます。

フルソルバーはいいだろうが、私は見ない理由理由のための開始点pip upgrade-allそれが何をしていることになることはありませべきではありませんpip install -U <list every package that's installed here>ません。 それは私がユーザーとして期待することであり、ほとんどの場合、それはまさに必要なことを実行します。 競合する要件に関する複雑なコーナーケースは、上記を参照することで最初に処理できます。 それでも不十分な場合は、 install -U動作を変更して対処するか、 update-allコマンドを特殊なケースに入れるか、その時点で完全なソルバーを実装することを検討できます。

今後10年間でこれを実装する予定ですか？

FWIW、私は今週末、これを再訪します。

@magicgooseは言った：
今後10年間でこれを実装する予定ですか？

@pfmooreは私ができるよりもそれを言った：

私たちは人々がこれを望んでいることを認識しています。不足しているのは、すでに提起されているさまざまな懸念や問題のすべてに対応する修正を開発することをいとわない人であり、PRレビュー中に必然的に発生します。

個人的には、少なくとも実装の開始点を提供する実用的なコードがない限り、この問題へのpingを控えていただければ幸いです。そして、実装まで進んで実行してください。

完全に個人的な意見

私はpipの性質上（debian、redhat、ubuntuなどのグローバルQAを持たないリポジトリからパッケージをインストールすることです）と思います
すべての機能の実装と更新を実際に完全に控えることが必要および/または許容できると感じています。

インストール可能なPythonパッケージのセットの既知の取得状態を保証するためです。

@RonnyPfannschmidt IMO要件/ワークフローに適合する場合、pipのユーザーがupdate-allコマンドの使用を明示的に禁止することは完全に合理的です。 しかし、pipのすべてのユーザーがこれらの人々と同じ厳格な要件を持っているわけではありません。 よりリラックスしたニーズを持つユーザーにとっては、update-allコマンドが便利であり、そのコマンドがないと、システムを「最新」に保つことが非常に困難になります。 したがって、pipがそのようなコマンドを提供することは合理的だと思います。 ユーザーがそれらのツールの使用を選択する方法に特定のポリシーを適用するのではなく、人々が必要とするツールを提供することが私たちの仕事です。

@pfmoore環境内のすべてのパッケージを更新するだけの私の個人的な経験は、それが非常に定期的に物事を壊すということです^^

リラックスしたアップデートが必要なユーザーはすべて、通常のエンドユーザーを意味するように聞こえます（たとえば、通常のLinuxディストリビューションを使用する必要があります）

アップグレード-すべてに問題があるかどうかは、依存関係の数と、APIのメンテナンスについてどれだけ統制されているかによって異なります。 また、各仮想環境で実行するアップグレードコマンドを慎重に構成するのではなく、キュレーションされたプライベートリポジトリと組み合わせて使用​​して、実際に行われるアップグレードを制御することもできます。

@RonnyPfannschmidt Windowsユーザーは依然としてLinuxユーザーの数を18対1で上回って

私たちは人々がこれを望んでいることを認識しています。不足しているのは、すでに提起されているさまざまな懸念や問題のすべてに対応する修正を開発することをいとわない人であり、PRレビュー中に必然的に発生します。

@pfmooreは、そのようなコメントが寄稿者の努力を性があることを知っていますか？ それが私にはどう見えるかです。 あなたがこの問題の全歴史をたどったかどうかはわかりませんが、この特定のケースでは、あなたは非常にオフベースです。 この問題は、貢献者よりもpip開発チームの方がはるかに重要です。

その一部の大まかな要約（PR gh-3194）：

1. upgradeコマンドを歓迎するという文書化された決定があります（pipメーリングリスト、ドキュメント、GitHubにあります）。
2. 次に、著名な開発者（この場合は@njsmith ）から、この機能を実装することは非常に価値があるという電話があります。
3. 新しい寄稿者が現れ、すべてを実装し、すべてのレビューコメントにすばやく対処します。 PRはマージする準備ができています。
4. コアコントリビューターは、 upgrade欲しいという考えを変えます。
5. 結論なしに、非常に長い議論が続きます。
6. コントリビューターはあきらめて消えます（ほとんどの人はそうするでしょう、そのようなことはイライラします）。

そしてそれは@pradyunsgが

うまく機能しているプロジェクトでは、この問題を本当に気にかけているコア開発者は、迅速なたまり場を組織し、ある種の決定を下します。 または、その結論を得るのに十分な作業を行うように1人または2人を委任します。 または、少なくとも、PR提出者を「フォロースルーしなかった」と非難するのではなく、謝罪して、PR提出者に感謝します。

あなたには最善の意図があることは知っていますが、この種のコメントにはもう少し注意してください。

特に、このような厄介な問題で正しい答えがない場合は、議論を通じて要件や意見を変えることは完全に合理的だと思います。 コードベースにパッチを適用することの一部は、変更に関するレビューとディスカッションの一部としてハッシュ化される変更に対応することです。 変更の中には、ごくわずかで少ないものもあれば、多いものもあります。 それに対処したくないと判断してドロップアウトする人には何の問題もありません（変更を追加するためのすべてのバーは、テスト、ドキュメントなどを含め、ある程度のドロップオフを引き起こします）。

この特定の変更は、pipの主な使用法のデフォルトの動作を変更するため、特に厄介です。 それは大変で恐ろしいことであり、私たちがそれを急いで、いずれかの方向にコミットする前に物事を完全にハッシュしなかった場合、それはユーザーにとって不利益になるでしょう。 このコマンドは、月に数千から数億回使用されます。 これは小さくて簡単な変更ではなく、変更を加えることから生じる怒りの反発に対処しなければならないのは、この問題にpingを送信する人々ではありません。

以前にPRを実施した方、お時間をいただきありがとうございましたが、最後までフォローしなかったのも事実です。 ここのコア開発者は時間に限りがあるため、私たちはボランティアであるか、多くのプロジェクトに分散しており、参加の内外に浮かんでいます。 注意が必要なさまざまな問題がたくさんありますが、これはそのうちの1つにすぎません。 Paulは、この問題にpingを実行することは役に立たず（役に立たない）、誰かがそれを望む場合は、誰か（コア開発者の1人を含む）がかなりの努力をすることを決定するのを待つ必要があると単純に述べました。数百万のデフォルトの動作を変更するか、自分でそれを行います。

私たちは人々がこれを望んでいることを認識しています。不足しているのは、すでに提起されているさまざまな懸念や問題のすべてに対応する修正を開発することをいとわない人であり、PRレビュー中に必然的に発生します。

@pfmooreは、そのようなコメントが寄稿者の努力を性があることを知っていますか？ それが私にはどう見えるかです。 あなたがこの問題の全歴史をたどったかどうかはわかりませんが、この特定のケースでは、あなたは非常にオフベースです。

@rgommers真剣に？ そのコメントは数ヶ月前のものであり、ここでは文脈から外れて引用されています（しかし、率直に言って、 @ pradyunsgが返信していた役に立たない皮肉なコメントに応えて引用しても問題ありません）。 歴史全体をレビューしておけば、私のコメントを文脈の中で見ていただろうと思います。その時点で、私が言おうとしていることを理解していただければ幸いです。

もし私がその「オフベース」だったとしたら、文脈から外れて、今それを選ぶのではなく、私が言ったときに5月にそう言ったかもしれません。

私が誰かを怒らせた場合、私は謝罪します、それは私の意図ではありませんでした。 正直なところ、私は他の誰と同じように、この問題が誰にでも受け入れられる設計に到達するのが非常に難しいことを証明していることに不満を感じています。 私のコメントでは、バランスをとろうとしています。一方では、人々の貢献に心から感謝していますが、他方では、このような問題について、率直に言って、コーディングは必要な作業の中で最も少ないものです。 多くの場合、寄稿者はこの事実を理解していません。そこで、PRが不完全になり、設計に問題がないことを人々に説得したり、変更をやり直したりするために必要な作業に人々が不満を感じるようになります。他の人の（しばしば矛盾し、一貫性のない！）見解を考慮に入れるのが本当に好きです。 非現実的な期待を抱いて結果として悪い経験をするのではなく、彼らが何が関係しているのかを理解してプロセスに入ったほうがいいです。

この問題に関する議論に関与するすべての人は、さまざまなアプローチの長所と短所を議論するために多くの時間を費やしました。 どれだけ時間がかかるか幸せな人はいないと思います。 個人的には、 upgrade-allコマンドの欠如（変更の一部であり、最初に実装される可能性は低い）が定期的に私を襲います。 私たちは時々（正直なところ、それは単に「たまに」以上のものです）人々（通常は実際に議論やコードに貢献していない人々）に「これは重要です、なぜあなたはまだそれを実装していないのですか？」 率直に言って、落ち着きを保つのは難しく、そのような人々にスナップすることはできません。

うまく機能しているプロジェクトでは、問題を本当に気にかけているコア開発者

このコメントは、pip開発者がこれを修正することを気にしない（そしてpipについての含意によって）と解釈される可能性があることをご存知ですか？ 私たちは皆、人々を怒らせるような言い回しの危険にさらされています。 ピップ開発者への批判としてこれを意味しているのではないと確信しています。私が同じように誰かを怒らせようとしているのではないと仮定してください。

簡単なたまり場を組織し、ある種の決定を下します。

そのようなことがここでうまくいくとしたら驚きますが、私はそれを試してみる気があります。 誰が関与するのか、どのように管理するのかはわかりませんが、それが役に立ち、誰かがそのアプローチを試したい場合は確かです。 この変更はピップユーザーに影響を与える可能性が非常に高いため、このようなプライベートチャネルで行われた決定は、おそらく提案として作成し、一般的なコメントのために公開する必要があります-そうすることで、単にトリガーされると思います私たちが行ってきた同じ議論のさらに別のラウンド。

または、その結論を得るのに十分な作業を行うように1人または2人を委任します。

それで、あなたはこれほど大きな決定が数人の人々によって一方的になされるべきであると言っているのですか？ おそらくそれが私たちが解決策を得る唯一の方法ですが、それは実際にはpipで決定が行われる方法ではありません（Pythonとは異なり、私たちは経営者の意思決定権限を持つBDFLを持っていません）。 あなたが望むなら、それは私たちを「うまく機能しているプロジェクト」ではないと主張することができます、それは私の見解ではありませんが、あなたが望むなら私たちはそれに反対することができます。

または、少なくとも謝罪し、PR提出者に感謝します。

何をお詫びするべきかわかりませんが、それが役に立ったら喜んでお詫びします-この提案を完成させるのがどんなに難しい仕事であるかを誰も彼に明確に理解していなかったという事実のために、または彼が討論を管理し、参加者をコンセンサスに導くのを助けました。 しかし、公平を期すために、当時、関係者がそうなることを知っていたとは思わないので、ここで話すのは主に後知恵だと思います。

彼は確かに私の感謝を持っています。 「言うまでもないことです」と言うのは簡単ですが、そうすべきではありません。オープンソースプロジェクトは貢献者に十分に感謝しておらず、それは問題です。 私がこのテーマに取り組んでいる間、この議論に貢献してくれた_everyone_に感謝したいと思います-そして私はここで完全に真剣です-経験からそれがどれほど消耗するかを知っています。 しかし、特に@pradyunsgは、すべての終わりのない議論と方向転換の現在の犠牲者でした。 あきらめないでくれてありがとう！ （まだ！！）

彼を「フォロースルーしなかった」と非難する代わりに。

まあ、私は何の責任も負わないと思います（彼はもう周りにいないので、彼が非難されたと感じたかどうかを知るのは難しいですが）。 しかし、彼の元のPRが完全に管理されなかったのは事実です。 しかし、それはただの事実です。 寄稿者がPRを提出したという理由だけでPRを受け入れる権利があることを誰も示唆していないことを願っています。 すべてのPRが最初に提出されたときに受け入れられるわけではなく、改訂および更新する必要があり、すべての作業を行った後でも、受け入れられない場合があります。 申し訳ありませんが、それは人生です。

[上記の声明で厳しいと思われる場合は、（もう一度！）お詫び申し上げます。 しかし、私の余暇の多くは、私（または私が関わっているプロジェクト）がどういうわけか十分に行っていない苦情を読んで対処することに費やされています。 そして、それは悪循環です-しつこいために、暇なときにオープンソースに取り組む意欲を失います。これはもちろん、やる気がさらに少なくなることを意味します。 礼儀正しくするように心がけていますが、簡単ではないこともあります]

PRがどのように管理されているかについてのこのメタディスカッションについて、これ以上何も言うつもりはありません。 私は今夜​​、誰かを怒らせるようなことを言わないようにするために、この応答に1時間費やしました（そして、私は失敗したに違いありません:-(）。またはより生産的な何かをしています。

では、 @ pradyunsgが私たち全員が満足できるPRを省くのを手伝うことに戻ることを提案できますか？

では、 @ pradyunsgが私たち全員が満足できるPRを省くのを手伝うことに戻ることを提案できますか？

はい、お願いします。 ：無垢：

ああ、忘れました。

@rgommersは言った：
そしてそれは@pradyunsgが

これを補足として取り上げます...ありがとう。

@pfmooreは言った：
特に@pradyunsgは、すべての終わりのない議論と方向転換の現在の犠牲者でした。 あきらめないでくれてありがとう！

どういたしまして。

（まだ！！）

その状態にならないことを心から願っています。 もしそうなら、それは本当に悪い状況になるでしょう、IMO。 （私はそのように傲慢です）

私は歴史を振り返りながら次のように書いたので、将来の参考のために、また万が一に備えて他の人に訂正してもらうために、ここに載せたほうがいいと思いました。

• 非技術的：技術的比率がどのようになるか（私が_本当に_保守的に考えていたよりもはるかに大きい）を認識し、これですでに失敗した試みがあったことを認識した後、これに取り組むことにしました。
• 私は退屈で、とにかく何が起こったのかを知る必要があったので、状況についての記事を書きました。
  
  
  
  • おそらく必要以上に多くの時間（そしてここにスペースがありますか？）を費やしましたが、少なくとも私は自分自身（そして他のすべての人？）のために問題の概要を把握しました。
  
  
• それを書いた後、興奮しすぎました。 ：smiley：それを世界に見せました！
• アップグレードコマンドの実装に関する（長い!!!）ディスカッションを開始しました。
  
  
  
  • いくつかの有用な派生アイデアが議論の中で浮かび上がりました。 同じために新しい問題が作成されました。
  
  
• 議論は、インストール動作をアップストールに変更するという考えにつながります。これは、デフォルトで非熱心なアップグレードを実行し、-targetオプション-3によって提供される機能の一部を削除します。
  
  
  
  • これは私たちが間違いを犯した場所です-3つの（かなり）独立した変更をバンドルし、誰もこの部分に気付いていないため、1つとして実装されます。
  
  
• 私は同じことを実装しました。 3つの変更がバンドルされていたため、インストール動作をアップストールに変更することについてコンセンサスが得られなかった場合、それらはすべてスタックしました。これは、潜在的に物議を醸す変更です。
• コンセンサスの欠如は長い議論を開始し、人々が議論から撤退するところまで来て、私はほとんど燃え尽き症候群に追いやられたと思います。
  
  
  
  • 以前の仮定のいくつかは破られ、最初に最小限の混乱の変更を行うことが決定されました。
  
  
• 私はこれに取り組むための自由な時間がなくなったので、他の誰かが独立してそれらに取り組むことができ、理想的にはここで行ったのと同じ間違いをしないように、いくつかの新しい問題を作成しました。
• ストールしました。
• 戻ってきました！ 9月25日までにデフォルトで非熱心なアップグレードに切り替えようとします。

はい、 pip install --upgrade修正に集中し、他のすべては今のところ省略しましょう。 それはとにかく他の仕事の要件です。

@ pfmoore @ dstufft思いやりのある返信をありがとう。 誰かを怒らせるつもりはなかったので、そのように出くわした場合はお詫びします。

誰もここで長い議論を探しているわけではないので、私はすべてに答えるわけではありません。

私が言った5月にそう言ったかもしれませんが

その時、私はGithubから2か月間離れていましたが、そのコメントを初めて見たときは気になりました。

それで、あなたはこれほど大きな決定が数人の人々によって一方的になされるべきであると言っているのですか？

テーブルのすべてのオプションは、現状よりもはるかに優れています。 そして5。5年後、ここの複数の問題/ PRとメーリングリストに何百ものコメントが広がった後、さらに多くのコメントがそれを解決するだろうと私は確信していません。 私はそれが解決されることを願っていますが、これが再び失速した場合は間違いなくそうです-1人または数人を指名して選択してください。

何をお詫びするべきかわかりませんが、それが役に立ったら喜んでお詫びします-この提案を完成させるのがどんなに難しい仕事であるかを誰も彼に明確に理解していなかったという事実のために、または彼が討論を管理し、参加者をコンセンサスに導くのを助けました。

私は後者を意味しました。 時々、自分のプロジェクトの1つを決定することに気が変わって、それが起こります。 そして、新しい方向性を明確にする責任があると感じています。 そして、その変更の結果に対処する時間がない場合はお詫びします（30秒しかかかりません...）。

しかし、彼の元のPRが完全に管理されなかったのは事実です。 しかし、それはただの事実です。

それは見解であり、事実ではありません。 私の見解では、PRは完了しました。あとは、緑色のボタンを押すか、拒否するだけでした。 彼は私が寄稿者に期待するすべてのことをしました。

あなたの返信の後で、pip開発者が貢献者やコア開発者に期待することは、私が精通している他のほとんどのプロジェクトとは非常に異なることに気づきました。 コア開発者が新しい貢献者を導き、励まし、必要に応じてフィードバックを提供し、論争のある問題（ほとんどの貢献者はスキルも関心も持たず、コア開発者になることが多い）を解決するのに役立つことを期待しています。必要です。 あなたは新しい貢献者にこう言っています：_「あなたは私たちを管理しなければなりません。私たちは私たちの考えを変えたり、お互いに意見を異にしたり、興味を失ったりするかもしれません-それを管理するのはあなたの仕事です」_。 たぶんそれがこのプロジェクトの性質であり、それはこのようでなければならない、私にはわかりません。

私がこのテーマについて話している間、この議論に貢献してくれたすべての人に感謝したいと思います

同意しました。 貢献してくれたすべての人に感謝します。

• そして私はここで完全に真剣です-私は経験からそれがどれほど消耗する可能性があるかを知っています。

排水中です。 個人的には、Pythonエコシステムとパッケージのユーザーにとって重要であるため、こことdistutils-sigに固執していますが、どちらの場所も私にポジティブなエネルギーを与えるわけではありません。

レーダーの下に滑り込んだ場合に備えて-＃3972：smile：

あなたは新しい貢献者にこう言っています：「あなたは私たちを管理しなければなりません。私たちは私たちの考えを変えたり、お互いに意見を異にしたり、興味を失ったりするかもしれません-それを管理するのはあなたの仕事です」。 たぶんそれがこのプロジェクトの性質であり、それはこのようでなければならない、私にはわかりません。

私はこれを続けないと言いましたが、この点は家に帰りました。 それは私たちのアプローチについて私が感じる方法ではありませんが、あなたがそれをそのように言った今、私はそれがそのように出くわすことができることを知っています。 正直に言うと、「考えを変えたり、意見を異にしたり、興味を失ったりする可能性がある」というのは真実です。結局のところ、私たちは皆、他のコミットメントを持っているだけの人々です。しかし、私はそれを新しい貢献者がしなければならないものとは考えていません。 "管理"。 むしろ、それは人と接するという現実に過ぎませんが、それをあまりにも多くすることは、新しい貢献者に問題を投げかけることとして出くわすのであれば、それは間違っています。

これを指摘してくれてありがとう-私はそれを心に留めて、将来その印象を与えることを避けるように努めます。

問題の多くは、私たちが非常に無人であるという事実に帰着すると思います。その結果、すべてを追跡し、フォローアップすることが困難になります。 私たちよりも潜在的な貢献者の方が多いので、一度に変更を加えようとしている人が複数いると、圧倒されがちです。 より大きな変更、または明確なコンセンサスがない変更は、対処するのが最も難しい傾向があるため、最も苦しむ傾向があるものです:(

悲しい状況は、私たち全員がプロセスを通じてすべての貢献者をガイドするためにここにいることを望んでいると思いますが、私たちには単に人的資源がないということです。 これも少し粘り気のあるサイクルになる傾向があります。私たちにはそれを行うための人的力がないため、ピップの動作の背後にある精神を実際に育て始めたようで、学んだ新しい人々をすぐに見つけることができません。 （私たちは彼らに教えるためにそこにいないので）彼らにピップへのコミット権を与えるのに十分です。 これは、私たちが常に無人で、頭を水上に保つためだけに苦労していることを意味します（少なくとも、それは私が感じる方法です。一定の70〜90時間の週は人にとって本当に難しいです：/）。

@pradyunsg Reviewing＃3972は私のTODOリストにありますが、まだヒットしていません。

@pradyunsg Reviewing＃3972は私のTODOリストにありますが、まだヒットしていません。

ありがとう！

これは、私たちが常に無人で、頭を水上に保つためだけに苦労していることを意味します（少なくとも、それは私が感じる方法です。一定の70〜90時間の週は人にとって本当に難しいです：/）。

それは難しいです。 NumpyとScipyは、私がそれらに取り組み始めたとき、そのような状況にありました。 楽しくない。 私はあなたがしているすべてに感謝します。

この問題は現在、非常に長く、非常に古く、多くのことが議論され、あまりにも多くのことが起こり、この問題はほとんど信号/ノイズが低くなっています。 すべてが起こったことを確認するのは難しいです。

FWIW、 upgradeがカードにある理由は、 install --upgradeデフォルトが壊れているためです。 これで修正に一歩近づいたので、新しい問題があるのが最善だと思います。

上記の理由でこの問題を解決し、ここで未解決と見なされるものについては新しい問題を作成することをお勧めします。 私は2つのことを見ることができます：

• デフォルトのアップグレード戦略をonly-if-neededシフトします。
• ＃988に依存する「世界をアップグレードする」機能を追加します。

2016年9月15日、NickCoghlanの[email protected]は次のように書いています。

@RonnyPfannschmidt Windowsユーザーは依然としてLinuxユーザーを18対1で上回っており、
ディストリビューションパッケージ管理コミュニティに匹敵するものはありません
この時点でフォールバックします（コアテクノロジーは最近そこにありますが
バージョン、パッケージングおよびキュレーションコミュニティはそうではありません）。 それは彼らが
pipやcondaなどのユーザーレベルのツールにはるかに依存して
スラック。

そうじゃない
conda update --all
十分ですか？

@ Liso77
いいえ、違います。

Condaとpipは、異なる目標を持つツールです。 これは、このトピックに関するすばらしい読み物です。 3番目のポイントが最も関連性があります。

アップグレードの議論が再び表面化した場合（できれば新しい問題で）、私の投票は次のように綴ることです：

pip install --upgrade :all:

pip install --upgrade :all:は非常に奇妙です。 基本的に今日誰もが行っているPOSIXセマンティクスに固執しましょう： pip install --upgrade --all

パッケージ名や指定子がないpip install --upgradeだけ

pip-toolsはpip-compile -Pこのようにします。

ある種の作業が終わったら、自転車小屋を使うべきかもしれません
実装... ：）

日、2017年2月12日には、午前20時55分FichteFoll [email protected]は書きました：

パッケージ名やパッケージ名なしでpipinstall--upgradeを実行するだけではどうでしょうか。
指定子？ 誤って走りやすい？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pypa/pip/issues/59#issuecomment-279225595 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADH7SfnSBflH8rK3nFLw1hvYBaovjbcGks5rbyRUgaJpZM4AJ4Py
。

どうのバージョンについてpip list --outdated直接できる形式でリストを作成する（すなわち、なしsed 、 cutなど）が摂取pip install --upgrade （たとえば、 pip list --outdated --format install | xargs pip install --upgradeまたはバックティックに類似したもの）？

使用される構文が何であれ、最も重要なことはこのコマンドを導入することです、それはまだ欠けている信じられないほどです

その間、私はあなたに試してみることをお勧めします
https://github.com/jgonggrijp/pip-review
pip-review --local --interactiveを使用すると、更新するかどうかをパッケージごとに尋ねます。あまり良くはありませんが、何もないよりはましです。

@ SMH17顧客に代わってPythonパッケージのユーザビリティの改善に取り組むための資金提供された開発時間を正式に提供している商用Pythonベンダーはまったくないため、まだ欠落していると完全に信じられます。

あなたは状況が改善してもらいたいのであれば、それはあなたが個人的に行うことができます最も有用なものは、あなたが使用するツールを改善する上で開発者の時間を投資するあなたのPythonのサポートベンダーを奨励するかのいずれかである可能性があります、またはあなたが持っていない場合まだサポートベンダーですが、雇用主に支払うように勧めてください。

この問題に関する緊急性の欠如に関する追加のコンテキストとして、一般的な推奨事項は次のとおりであることを覚えておく価値があります。

• 作業環境の定義をソース管理下に置いて、他のシステムでの再現性を向上させます（https://github.com/jazzband/pip-toolsやhttps://github.com/kennethreitz/pipenvなどを使用して、これらの定義を最新の状態に保ちます） ）。
• 未知または非公開のセキュリティ脆弱性への露出ウィンドウを最小限に抑えるために、依存関係の新しいリリースに定期的にアップグレードすることを目指します

これは、ここで提案されたコマンドが役に立たないという意味ではありません。現在の作業環境がpip-compile + pip-sync 、またはpipenv lockを通じてすでに維持されている場合、コマンドの価値は著しく低くなります。 pipenv install 。

@qwcodeによる更新以降、 pip installいくつかの変更が加えられたと思われるため、元の説明を更新することは価値があります。

皆さんこんにちは。

次のコマンドが原因で、Pythonパッケージの依存関係の一部が壊れました。

pip install --upgrade packageNameはパッケージを再帰的にアップグレードしました。

--upgradeオプションのデフォルトの動作を変更してみませんか？つまり、コマンドラインから指定されたパッケージのみをアンインストールして再インストールしますか？

これはどう ？

@sebmaデフォルトの動作は変更すべきではないと思います。 次回は-no-dependenciesフラグを使用してみることができます。 動作するはずです：+1：

@ sebma 、 @ aaossa 、デフォルトのアップグレード戦略が将来変更されることがすでにほぼ決定されていることを両方とも知ってもらいます（参照：https：//github.com/pypa/pip/issues/3871# issuecomment-247789343）。 必要な機能（つまり、 --upgrade-strategy引数）がhttps://github.com/pypa/pip/pull/3972に追加されました

@pradyunsgが前述したように、この問題は一種の残り物です。 最初の部分は今ではある程度処理されており（私の最初の段落を参照）、2番目の部分がこのパッケージがまだ開いている唯一の理由のようです。 それ以降、別の「すべてアップグレード」の問題が発生したかどうかはわかりません。

要件ファイル用の優れたインタラクティブアップグレーダーをリリースしました： https ：

デフォルトのアップグレード戦略を必要な場合のみにシフトします。

4500がこれを行いました。

＃988に依存する「世界をアップグレードする」機能を追加します。

これについての議論のための4551。

現在のトップポストでなされたポイントに対処する：

pipアップグレードは、デフォルトで非再帰的である（そして--recursiveオプションを提供する）ことを除いて、pip install--upgradeに似ています。 現在の再帰的なデフォルトの動作は、多くの人に悲しみをもたらしています（＃304）。 非再帰的なアップグレードを今行う方法については、ここを参照してください。

アップグレードコマンドを追加したり、pip installupgradeをすでにインストールされているパッケージにすることはできません。 pipには、デフォルトで非再帰的なアップグレードがあり、再帰的な動作は--upgrade-strategy eager背後で利用できます。

pip upgrade-allは、インストールされているすべてのパッケージをアップグレードします。

4551が存在し、これについて新たな議論をするのは素晴らしいことです。 ＃988が完了したとき。

@dstufft @xavfernandez @pfmooreこの問題を解決する必要があると思う人はいますか？

_{編集（2017年5月18日）：句読点+マイナーテキストが追加されました}

合理的なようです。

皆さんこんにちは、
私はその仕事をする簡単なスクリプト/要点を作りました。

https://gist.github.com/serafeimgr/b4ca5d0de63950cc5349d4802d22f3f0

なぜこれを単純にしないのですか？

pip install --upgrade $(pip list --outdated | awk '{print $1}' | tr '\n' ' ')

他のパッケージの依存関係の一部を満たさないバージョンをインストールする可能性があるため、実際にはそれほど簡単ではないためです。

@serafeimgrの要点に基づいて、そしてそのおかげで、おそらく便利なコマンドラインツールpip_upgrade_outdatedを作成しました。 githubのソース。 フィードバックを歓迎します。

（この問題も参照してください：はい、並列実行は特に危険です。はい、これは問題を引き起こす可能性があります。それでも、多くの人がこのようなものを常に手作業で実行しているので、役立つかもしれません。）

完全なソリューションを構築するために時間を割いていただきありがとうございます。
私の推奨は、この機能をpipにプッシュする方法を見つけることですが。

とにかく、pipenvとpipfileがpip /requirements.txtに取って代わると思います。
たぶん、 @ kennethreitzはロードマップと--upgradeall機能についてもっと知っています。

@qoheniac | tr ...は冗長です。

このスレッドは、閉じられた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、新しい問題を開いてください。