pip3からの出力は次のとおりです。

werner in ~ at octopus23
➜ pip3 install pipenv
Collecting pipenv
  Using cached https://files.pythonhosted.org/packages/2c/01/37a5867a47d52856b077d0faa561b791cb6e6e3e9410837b6d62f569c1e6/pipenv-11.10.1-py3-none-any.whl
Collecting virtualenv (from pipenv)
  Using cached https://files.pythonhosted.org/packages/ed/ea/e20b5cbebf45d3096e8138ab74eda139595d827677f38e9dd543e6015bdf/virtualenv-15.2.0-py2.py3-none-any.whl
Collecting pip>=9.0.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/0f/74/ecd13431bcc456ed390b44c8a6e917c1820365cbebcb6a8974d1cd045ab4/pip-10.0.1-py2.py3-none-any.whl
Collecting setuptools>=36.2.1 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/8c/10/79282747f9169f21c053c562a0baa21815a8c7879be97abd930dbcf862e8/setuptools-39.1.0-py2.py3-none-any.whl
Collecting virtualenv-clone>=0.2.5 (from pipenv)
  Using cached https://files.pythonhosted.org/packages/6d/c2/dccb5ccf599e0c5d1eea6acbd058af7a71384f9740179db67a9182a24798/virtualenv_clone-0.3.0-py2.py3-none-any.whl
Collecting certifi (from pipenv)
  Using cached https://files.pythonhosted.org/packages/7c/e6/92ad559b7192d846975fc916b65f667c7b8c3a32bea7372340bfe9a15fa5/certifi-2018.4.16-py2.py3-none-any.whl
Installing collected packages: virtualenv, pip, setuptools, virtualenv-clone, certifi, pipenv
Successfully installed certifi-2018.4.16 pip-10.0.1 pipenv-11.10.1 setuptools-39.1.0 virtualenv-15.2.0 virtualenv-clone-0.3.0

これはピップによってはPipenvの結果である可能性が高いと思いますが、Pipenvがこれに責任があるかどうかはわかりません。 Pythonとpipの結合を壊したのは彼らだからかもしれませんが、Debianはそうすべきです。 確かに、pipによっては、Pipenvだけがパッケージではありませんが、ここでのベストプラクティスはわかりません。

@ncoghlanこのトピックに関する洞察を提供して

1. パッケージはpipに依存する必要がありますか？
2. 1.が「はい」の場合、システムパッケージマネージャーとのこの種の競合の原因となる必要がありますか？
3. 2.が「はい」の場合、どのように？
4. 2.が「いいえ」の場合、誰が責任を負うべきですか？ 代わりに回避策を使用するようにユーザーに指示する必要がありますか？

いずれにせよ、Ubuntuではsudo pip installを絶対に使用しないでください。 代わりに、次のいずれかを実行する必要があります

• APTを最後まで使用する
• pip install --user
• pipsiなどのカスタムマネージャー

または、さらに良いことに、システムPythonを完全に避け、代わりにpyenvまたは他のPythonランタイムマネージャーを使用します。

それらをスクラッチします。 APT、期間からPythonを避けてください。

とにかくUbuntuに何かをsudopipインストールするべきではないでしょう

私は実際にやったことはありません。 Ubuntuでsudo pipを使用する際の問題を認識しているので、可能な限りaptを使用するか、 --userます。

ああ、私は今問題を見ています。 ユーザーモジュールはシステムモジュールよりも優先されますが、 /usr/binはPATH $HOME/.local/binにあります。 /usr/bin/pythonはシステムpipインストール（まだ9.x）をインポートしようとしますが、ユーザーインストール（10.x）を見つけることになりました。 なんてめちゃくちゃ。

2095も同じですが、フレンドリーなPATHを持っているユーザーに依存するよりも堅牢なソリューションがあるはずなので、これを開いたままにしておきたいと思います。

ユーザーが持っているときはかなり安定しています：

• ユーザーのPATHの先頭にある˜/.local/bin PATH 。 16.10以降、Ubuntuのデフォルトになります。 完全に有効なユースケースであるpip install --user動作が可能になるため、これを使用することをお勧めします。
• ユーザーは常にpip install --user使用する必要があります。 システムのpipをいじることは、すべてのディストリビューションで本当に悪いことです。debianの奇妙な「dist-packages / site-packages」フォルダでさえ、ユーザーのミスから保護していません。

私たちはすべてのubuntuユーザーインストール（さまざまなubuntuバージョンの1000以上のインストールの組織）でこの動作を保証し、pip10への移行は魅力のように機能しました。

Pythonとそのエコシステムは複雑であり、検索順序を正しくするためにパスを適切に構成する必要がない方がよいことに同意しますが、残念ながら、これはパッケージマネージャーでのインストールの現在の動作に関する事実にすぎません。そして、それ自体は正確にはpipenvの問題ではありません。 独立して取り組むためにできることはあまりないと思います。Pythonのメーリングリストで対処する必要がある問題です。

ああ、私は今、問題が何であるかを理解しています、ありがとう。 パスがこれに影響を与える可能性があるとは思わなかったので、問題の説明にパスを含めることは私には思い浮かびませんでした。 申し訳ありませんが、ご協力いただきありがとうございます。

私にとってそれを修正したのは追加でした

export PATH="${HOME}/.local/bin:$PATH"

プロファイルに。

編集：この変更を有効にするには、必ずhash -rを実行するか、新しいシェルを入力してください。

自主的に取り組むためにできることはあまりないと思います

おそらく、より詳細なインストール手順や警告がある可能性がありますか？ 私はpipの仕組みについてあまり経験がありませんが、パスの問題に関するメモを読んだことがあるかもしれません。 しかし、さまざまなパッケージマネージャーとディストリビューションのエコシステムは、単純なルールには複雑すぎると思います…

@slhck実際には非常に苛立たしいので、数日前にPython環境とsudoおよびパッケージマネージャーのインストールについて特にこのxkcdがありました

これが私がUbuntu18.04でうまく使った素晴らしいステップバイステップガイドです：
https://phoikoi.io/2018/04/03/bootstrap-pipenv-debian.html

https://github.com/pypa/python-packaging-user-guide/issues/396もありPATH / sys.path順序の競合の可能性についてメモしておきます。

ありがとう、 @ slhck 。 あなたのエクスポートの回避策は私に最も時間を節約しました。 / etc / profileに追加しました。

Linuxに2つのレベルのソフトウェアパッケージがあるのは本当にばかげています。 さらに悪いことに、* buntusの最新リリースでは、そのうちの1つ（pip / pip3）の両方のフレーバーが壊れています。

Launchpadに書きました： https ：

@texadactyl Debianには、pipはデフォルトでインストールされるべきではないというこのポリシーがあり（私はそれが何であるかを忘れています）、彼らは以前の多くの苦情でそれに固執しています。 その伝統はDebianのルーツに深く根付いています。 彼らがこれを再考することができれば私はうんざりするでしょう、しかし私は彼らがそうすることを非常に疑っています。

私はUbuntu18とPython3.6で同じ問題に直面していました

以下は私が従ったステップです：

1）最初に私はエラーを受け取っていました：

トレースバック（最後の最後の呼び出し）：
ファイル "/ usr / bin / pip"、9行目
pip importmainから
ImportError：名前mainをインポートできません

2）/ user / bin / pipファイルを次のように変更しました。

sysをインポート
pip._internal importmainから_mainとして
if __name__ == '__ main__'：
sys.exit（main（））

3）それから、それは私にこのエラーを与え始めました：

トレースバック（最後の最後の呼び出し）：
ファイル "/ usr / bin / pip3"、行11、
sys.exit（main（））
NameError：名前 'main'が定義されていません

4）/ usr / bin / pip3を次のように変更しました。

sysをインポート
pip._internal importmainから_mainとして
if __name__ == '__ main__'：
sys.exit（_main（））

5）それから私はエラーを受け取り始めました：

トレースバック（最後の最後の呼び出し）：
ファイル "/ usr / bin / pip3"、11行目
sys.exit（main（））
NameError：名前 'main'が定義されていません

6）main（）の名前を_main（）に変更しましたが、出来上がりです。 :) :)

それで問題は解決したかもしれませんが、これはかなり悪いアドバイスです。 システムファイルを手動で変更しないでください。 解決策については、以前のコメントをご覧ください。

編集： @slhckのソリューションはそれを解決しました。 パスに~/.local/binが必要です

ubuntu16.04で同じ問題が発生します。

$ sudo apt install python3-pip
$ pip3 --version
pip 8.1.1 from /usr/lib/python3/dist-packages (python 3.5)
$ python3 -m pip install --user pipenv
$ pip3 --version
Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

# revert back and fix pip
$ sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

私もこの問題に遭遇したことを付け加えたいと思います。 私はすでに〜/ .local / binを私のパスの最初のものとして持っていました。 問題は、bashがコマンドをハッシュする方法です。 この問題の解決策はここにあります： https ：

@thernstigはい、その通りです。必要なhash -rコマンドを上記のソリューションに追加しましたが、明示的に言及するのを忘れていました。

@slhck問題ありません、お手伝いできてうれしいです

問題が解決したことに気づきましたが、これがPATHの変更を回避するのに役立つことを願って投稿しています。 私は今日、新しいUbuntu 18.04マシンをセットアップするときにこれに遭遇し、再起動しましたが、PATHを変更せずに解決できました（ログアウト/ログインが機能することはかなり確実ですが、確認しませんでした）。

python3-pipを介してpip3をインストールし、 pip3 install --user pipenvを使用してpipenvをインストールした後、サブジェクトエラーが発生しました。 ~/.profile次のことに気付いたとき、 @ slhckからの回避策を使用しようとしていました（在庫、変更はありません）：

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

不思議なことに、私は再起動しましたが、確かに、 .local/binがPATHの先頭にあり、pip3が再び機能したため、問題は解決しました。

@jlitzingerdevパスがデフォルトであると確信しています。これは、システムの場合と同じです。別のシェルとプロファイルを使用していたため、パスを削除するか、最初から作成しました。したがって、「回避策」は必要ありませんでした。そもそも。 あなたがそれを理解してくれてうれしいです。

@slhckですが、 ~/.local/binが存在しない可能性があるため、最初のログイン時にPATHに含まれていない可能性があります。これは、私の特定のケースでした。

やらなければいけないことは何？

復元コマンドを含めていただきありがとうございます。pipを再び機能させるのに問題がありました。

Ubuntu18.04にpipenvをインストールしたい。 そうすると、pip / pip3が壊れます。

期待される結果

インストールされ、動作しているバージョンのpipenv。

実結果

pip / pip3は、pipまたはpip3のどちらを介してpipenvをインストールしたかによって、壊れています。

➜ pip
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

複製する手順

1. Set up Ubuntu 18.04

2. Run `pip install pipenv` or `pip3 install pipenv`

3. Run `pip` or `pip3` – the error is printed, and pip / pip3 do not work anymore.

この問題を修正するには、次のコマンドを実行する必要があります。

sudo python -m pip uninstall pip && sudo apt install python-pip --reinstall
sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

しかし、pipを使用してpipenvをインストールすることはできません。 利用可能なPPAがないため、 aptを介したインストールは機能しません。

私はubuntuに3つのpipを持っています18pip、pip3とpip3.6pipは2.7用ですpip3は3.5用でpip3.6は3.6用ですこれでpipは.local / binのファイルの場所を示します。 ここからファイルpipとpip3を削除しました。 これで、どのpip3が/ usr / bin / pip3を表示します。 コマンドsudonano / usr / bin / pip3を実行して、インタープリターの最初の行を！＃/ usr / bin / python3から＃/ usr / bin /python3.5に変更します。 私のために働く。 私のピップはすべて機能します。 これがお役に立てば幸いです

私はubuntuに3つのpipを持っています18pip、pip3とpip3.6pipは2.7用ですpip3は3.5用でpip3.6は3.6用ですこれでpipは.local / binのファイルの場所を示します。 ここからファイルpipとpip3を削除しました。 これで、どのpip3が/ usr / bin / pip3を表示します。 コマンドsudonano / usr / bin / pip3を実行して、インタープリターの最初の行を！＃/ usr / bin / python3から＃/ usr / bin /python3.5に変更します。 私のために働く。 私のピップはすべて機能します。 これがお役に立てば幸いです

これらすべての手順は実際には推奨されていません。 /usr/bin内のファイルを手動で編集しないでください。 代わりに、上記のようにpipをアンインストールし、 apt介して再インストールしてみてください。 これにより、正しいシステムインストールが可能になります。 その後、 pipenvで問題が発生した場合は、そのような回避策を試みるのではなく、新しい問題を開いて問題を説明してください。

上記のようにaptを介して再インストールしても、同じ出力が生成されるため、何も変更されません。 単純な状態では、名前mainをインポートできず、Pythonインタープリターでimport pipを実行すると、モジュールとしてインポートされます。つまり、名前mainは、検索しようとしているモジュールでは使用できません。 今、私は上記の編集を盲目的に提案しませんでした。 私がubuntu14を使用していたときのソフトウェア愛好家として、私はpipファイルをチェックしましたが、それはubuntu18pip3のものと同じコードを持っています。 だから何が変わったのか。 あらかじめパッケージ化されているPythonバージョンはそうしました。

python3.5および2.7のpipには、pipモジュールで定義されているmainのみがあるためです。
そして、python3.6ではpip._internalで定義されています

今、上記の2つのステートメントはみんなの問題を解決します

問題は、それ自体を使用するインタプリタにあります

python3; しかし、どのPythonを参照していますか
python 2.7のみを使用し、ubuntu18に変更した開発者は、python3をpython3.6として使用する可能性があります。

しかし、python3.4 pr3.5をインストールした人はどうでしょうか。 最初にpython3.5を参照し、アップグレード後にppython3.6を参照します。

それで、それがdebianによって処理された方法はそれを壊しました

正しい通訳を述べるだけで問題は解決します
両方にエラーがあります

pip importmainから
と
pip._internal importmainから_mainとして

ありがとう
ps
この時点で、他のプラットフォームでは問題がないことを講義する必要がありますが、他の情熱的な開発者がそこで厄介な問題を解決するためにやってくるgithubでは; 特に、彼らがたくさんのコマンドを実行したり、いくつかの設定ファイルを編集してそれを実行しようとしているとき、私はあなたがこのような人々を落胆させ始めるほど賢くないと言わなければなりません。

注：新しいバージョンは、コードを変更しないと機能しません。 彼らはそれがそれをアンインストールしてインストールするすべての人のために働くように回避策を追加します

この時点であなたがそれを手に入れることを願っています。 平和と私を再び気にしないでください

@ r-tron18システムファイルを変更しないように、建設的な提案として意図されたものによって講義されたと感じて申し訳ありません。 元の投稿で提供していた小さなコンテキストから、自分が何をしているかを知っている経験豊富なユーザーなのか、他の場所で見つけた可能性のある回避策を適用しただけなのかを判断することは不可能でした。 私はさまざまなトラブルシューティングやQ＆A Webサイトに多くの時間を費やしていますが、ユーザーにランダムな修正を試したり、システムに出荷されたファイルをsudo編集したりすることを勧めるべきではないことに同意するでしょう。エラーと混乱。 それはもっと一般的な問題です。

私はあなたが提案していることが信頼できる解決策であるとまだ確信していません。 そして：そのソリューションのメリットについて市民の議論をすることができます—GitHubは私がそれを表現することを許可されている場所です。

理由は次のとおりです。 /usr/bin/pip3のシェバンを#!/usr/bin/python3.5と、そのバージョンに固執するだけです。 #!/usr/bin/python3 、 /usr/bin/python3.6 （またはシステムに現在存在するもの）へのシンボリックリンクである必要があります。 Pythonをアップグレードすると、とにかくそのファイルが変更される可能性があります。

あなたは言う：

しかし、python3.4 pr3.5をインストールした人はどうでしょうか。 最初にpython3.5を参照し、アップグレード後にppython3.6を参照します。
それで、それがdebianによって処理された方法はそれを壊しました

Python3.5からPython3.6にアップグレードした後、そのpython3シンボリックリンクが更新されなかったと言っていますか？ 観察しているのが実際にDebianまたはUbuntuのバグであり、Pythonのアップグレードで正しいシンボリックリンクを設定できなかった場合、そのバグはおそらくアップストリームで対処する必要があります。

問題が解決したことに気づきましたが、これがPATHの変更を回避するのに役立つことを願って投稿しています。 私は今日、新しいUbuntu 18.04マシンをセットアップするときにこれに遭遇し、再起動しましたが、PATHを変更せずに解決できました（ログアウト/ログインが機能することはかなり確実ですが、確認しませんでした）。

python3-pipを介してpip3をインストールし、 pip3 install --user pipenvを使用してpipenvをインストールした後、サブジェクトエラーが発生しました。 ~/.profile次のことに気付いたとき、 @ slhckからの回避策を使用しようとしていました（在庫、変更はありません）：

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

不思議なことに、私は再起動しましたが、確かに、 .local/binがPATHの先頭にあり、pip3が再び機能したため、問題は解決しました。

再起動した後はすべて正常に動作します。 （インストール後： "pip3 install --user pipenv"システムを再起動すると、動作します。