だから私はこれを読んだ-https://wiki.archlinux.org/index.php/Python
そして、このwikiから、Python2.7.2を経由してインストールできることは明らかです。
pacman -S python2
python2へのシンボリックリンクを作成するのは合理的ですか？
ln -s python2 /usr/bin/python
すぐにPython3.0に切り替えるとは思わない場合はどうすればよいですか？または、debianシステム（update-alternatives --config python）やmac os xシステム（python select）で通常使用しているような複数のPythonバージョンを管理するためのより良い方法はありますか？
明確化：
このようなシンボリックリンクを作成するべきではないと私は主張します。特に、Pythonコードの一部を配布する場合は、ユーザーが/ usr / bin/pythonにpython2またはpython3を持っていると想定しないでください。
スクリプトにpython2が必要な場合は、次を使用してください。
#!/usr/bin/env python2
スクリプトにpython3が必要な場合は、次を使用します。
#!/usr/bin/env python3
このようにして、Pythonを更新してもスクリプトは正常に機能します。また、スクリプトが実際に必要とするバージョンもはるかに明確になります。
ほとんどのユニスにはすでに/usr/ bin/pythonがあります。これはシステム内のすべてのパッケージで使用されるPythonバージョンであるため、これを上書きすることはお勧めできません。これを変更すると、パッケージが破損する可能性があります。Python 2.7パッケージをインストールするときは、実行可能ファイルを/usr/bin/python2.7としてインストールする必要があります（そうでない場合は、Archlinuxが壊れていると主張します）。Python2.7を実行する場合は、これを使用することをお勧めします。
Archlinuxは、Python3のデフォルトの実行可能ファイル名が/usr / bin / python3であるにもかかわらず、Python3に/usr / bin / pythonを使用するため、少し特別です。これは紛らわしく、バグと見なされる可能性がありますが、Python 2にそのシンボリックリンクを使用できないことを意味します。Python3を使用する他のArchlinuxスクリプトを使用すると、ほぼ確実に機能しなくなります。
したがって、他のユニスでは/ usr / bin /pythonをPython2.7にシンボリックリンクすることは悪い考えですが、Archlinuxではひどい考えです。代わりに、必要なすべてのバージョンをインストールし、/ usr / bin/pythonX.Xで呼び出します。
githubには、 pyenvと呼ばれる素晴らしいプロジェクトがあります 。複数のPythonインスタンスの管理に役立ちます。
他の人が言っているように、短い答えは「これをしないでください、それはあなたのシステムで物事を壊す可能性が高いです」です、しかしあなたが主にPython 2を使うなら、あなたはまだあなたのシェルであなたの個人的なデフォルトを設定することができます（そしてそれでもいつでもPython3に切り替えるオプション）。これを行うには、最初にrootになり、インストールしpython2-virtualenvます。
# pacman -S python2-virtualenv
次に、Python 2を使用する仮想環境を作成します（これにより、Python、setuptools、wheel、およびpipが環境に自動的にインストールされます）。
$ virtualenv -p /usr/bin/python2 --system-site-packages ~/env # (Or wherever you want your environment to live)
ローカルにインストールされたパッケージ（たとえば、pipでインストールし、によってインストールされたパッケージではないパッケージ）のみを使用する場合は、環境を作成するときにオプションをpacman削除します。--system-site-packages
次に、~/.bash_profileまたは~/.profile（または任意のシェル構成ファイル）で、次のように設定します。\
source ~/env/bin/activate
これにより仮想環境がアクティブになり、デフォルトバージョンがPython2になります。
これにより、シェルで起動されたものがすべて破損する可能性がありますが、シェルから明示的に実行していない限り、何かが破損する可能性は低くなります。その時点で、次を実行して仮想環境をオフにできます。
deactivate
または、Python3を手動で実行します。
私はこの投稿に偶然出くわしました。ネクロバンピングは意図されていませんでしたが、virtualenvsについて誰も言及していないのではないかと思っていました。私もArchLinuxを使用しており、Pythonパッケージvirtualenvとvirtualenvwrapperを使用して複数のPython環境を作成しています。/ usr / bin/にあるpython2またはpython3バイナリを参照して、仮想環境で使用されているpythonバージョンを確認できます。
利点は、仮想環境にインストールされたパッケージが、システムが使用しているPythonを混乱させず、プロジェクトの処理を自動化する多くの方法があることです。
これは非常に古い答えかもしれませんが、問題を解決するのに2日かかったので、共有します。
システム内のPythonバージョンを管理して、さまざまなプロジェクトに夢中にならないようにする適切な方法は、Henrique Bastosがこのブログ投稿で説明しているように、 pyenvとそのプラグインpyenv-virtualenvおよびpyenv-virtualenvwrapperを使用することです。pyenvはPythonパッケージであり、Windows、Linux、Mac OSxでもまったく同じように実行できるため、この方法はプラットフォームに依存しないことに注意してください。
問題はArchLinuxから始まります。OSはpyenvのpacmanバージョンを提供していないため、リリースのインストールセクションで説明されているように、githubからクローンを作成してインストールする必要があります。インストールプロセスは、pyenv-virtualenvとpyenv-virtualenvwrapperの両方で同じです。シェルの初期化構成が異なる場合があることに注意してください。私の場合、〜/ .bash_profileでは機能しませんでしたが、〜/.bashrcでは機能しました。
pipにはopenSSLが必要であり、pacmanを介してインストールしても、pyenvはそれを認識しないため、最近セットアップしたもののようにインストールが非常に新鮮な場合、pyenvの実行は簡単ではありません。したがって、古いバージョンのPython（つまり、3.4.3）をインストールする場合は、openSSLプラグインがインストールされていても、インストールされていないことを示すシェルが表示されます。正直なところ、最初にインストールしようとしたときは、適切なパッケージがありませんでした。次のパッケージをダウンロードする必要があります
sudo pacman -S openssl
sudo pacman -S openssl-1.0
sudo pacman -S python-pyopenssl
sudo pacman -S python2-pyopenssl
私が問題を解決した方法は、pyenvのインストールに関するFAQで説明されているようにフラグを追加することです。その解決策により、最終的に必要なPythonバージョンをインストールすることになりました。
LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv install -v 3.4.3
Pythonインストール環境を更新するたびにFAQページに移動しないようにするには、次のように〜/.bashrcまたはシェルにエイリアスを追加します。
echo alias pyenv='LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv' >> ~/.bashrc
このようにして、クリーンなpyenv構文を使用してPythonを適切にインストールし、同じ方法でプラグインを介してPythonを管理できます（構文はpyenv [COMMAND] [OTHERSTUFF]であるため）。
いいえ、これを行うためのより良い方法はありません。pythonシンボリックリンクはPython3パッケージの一部です。
このリンクを変更しても今のところ何も壊れないと思いますが、将来的には一部のパッケージがそれに依存する可能性があります。