かなり新しいUbuntu 16.04で、ユーザーインストールとして、pipでipythonをインストールしています。 Pip自体はpython-pip
Ubuntuパッケージ(8.1.1)からインストールされたため、pygmentsやsetuptools(20.7.0)などの依存関係もインストールされています。
私の質問:pipを使用してユーザーインストールを行ったときに、apt-getインストール済みパッケージが検出されないのは正常ですか?既知のバグですか?
これは私が実行するコマンドです(rootとしてではなくユーザーとして):
$ pip install ipython
→setuptool(27.3.0)やPygments(2.1.3)など、PyPIから多くのパッケージをダウンロードできます。 ipythonにはsetuptools>=18.5
のみが必要なので、バージョンの問題だとは思いません。ちなみに、pipを最新バージョン(8.1.2)に更新する必要があるという苦情もあります。
さらに興味深いことに、同じコマンドを再度実行すると、同じインストールプロセスが行われます(違いは、ホイールがキャッシュされるだけです)。代わりに、ipythonが既にインストールされていることを示すpipが期待されます。
Ipython(バージョン5.1.0)が実際に~/.local
ディレクトリにインストールされ、うまく動作することに疑いの余地がないことに注意してください(私がしなければならなかった唯一の調整は~/.local/bin
をPATH
変数に追加することでした 専用の質問 )で述べた~/.bashrc
。
Pipがインストールされたapt-getパッケージを検出する方法に何か問題があるように思えますが、何がわかるのかわかりません。明らかな何かが欠けていますか?
診断に役立つ場合、これはPythonモジュールパスです(modelicaはユーザー名です):
python -c "import sys; print sys.path"
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/modelica/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/omniORB/COS', '/usr/lib/python2.7/dist-packages/gtk-2.0']
pipを使用してユーザーインストールを実行すると、apt-getインストール済みパッケージが検出されないのは正常ですか?既知のバグですか?
私はちょうどpipのコードに飛び込み、pipのlist
コマンドが pkg_resources.WorkingSet() によって提供されるパッケージのリストをフィルター処理することがわかりました。このリストはsys.path
からエントリを取得します。その結果、pip --list
はAPTによってインストールされたシステムパッケージもリストします。しかし、pipがこのパッケージを管理する必要があるという意味ではありません。
PipとAPTは、インストールする場所から始めて、動作が異なります。pipは、/usr/lib/pythonX.Y/site-packages
または/usr/local/lib/pythonX.Y/dist-packages
(バージョンに応じて)にグローバルにインストールされ、~/.local/lib/pythonX.Y/site-packages
にローカルにインストールされます。APTベースのツールは、/usr/lib/pythonX.Y/dist-packages
にグローバルにインストールされます。
この奇妙なことに関連するのは、 Debian開発者による設計決定 提供されたパッケージと他の手段で取得されたパッケージとの競合を避けるためです( このStack Overflowの回答 右に指摘しました方向)。
そのため、パッケージが既に~/.local/lib/pythonX.Y/site-packages
にインストールされていても、pipを使用してパッケージを/usr/lib/pythonX.Y/dist-packages
にインストールできるのはバグではありません。
Ipythonの例を見てみましょう。また、以前にAPTでインストールしました:
$ dpkg --get-selections | grep ipython ipython install $ dpkg -s ipython | grepバージョン バージョン:2.4.1-1 $ dpkg-query -L ipython (...) /usr/lib /python2.7/dist-packages (...) /usr/bin/ipython (...)
$ pip show -f ipython (...) 名前:ipython バージョン:5.3.0 (...) インストーラー:pip (..) Location:/usr/local/lib/python2.7/dist-packages Files: ./../../bin/ipython
注:../../../bin/ipython
は/usr/local/bin/ipython
になります。
コマンドwhereis
は、2つのIPythonインスタンスを提供します。
$ whereis -b ipython
ipython: /usr/bin/ipython /usr/local/bin/ipython
そして、もし望むなら、~/.local
で3番目のIPythonを取得できます!
さらに興味深いことに、同じコマンドを再度実行すると、同じインストールプロセスが行われます(違いは、ホイールがキャッシュされるだけです)。代わりに、ipythonが既にインストールされていることを示すpipが期待されます。
これは確かに奇妙に思えます。これは私がこれまでに観察したことです:パッケージがすでにpipによってローカルにインストールされている場合、毎回インストールするように見えます(常に「Successfully installed {package}」を出力します)が、実際にはパッケージdist-infoを変更するだけです。たとえば、lxmlをローカルに(pip install lxml
またはpip install --user lxml
を使用して)数回インストールしようとしました。
最初のlxmlインストールのタイムスタンプと最後のlxml「インストール」の後のタイムスタンプを比較します。
1。
myusr @ myhost:〜$ ls -al .local/lib/python2.7/site-packages | grep lxml drwxrwxr-x 5 myusr mygroup 4096 feb 20 15:01 lxml drwxrwxr-x 2 myusr mygroup 4096 feb 20 15:01 lxml-3.7.3.dist-info
2。
myusr @ myhost:〜$ ls -al .local/lib/python2.7/site-packages | grep lxml drwxrwxr-x 5 myusr mygroup 4096 feb 20 15:01 lxml drwxrwxr-x 2 myusr mygroup 4096 feb 20 15:03 lxml-3.7.3.dist-info
ただし、パッケージをグローバルにインストールしようとすると、pipdoesがメッセージを表示します。
Requirement already satisfied (use --upgrade to upgrade): ipython in /usr/local/lib/python2.7/dist-packages
試して
python3 -m pip install ipython
私のために