archlinuxでPython）の複数のバージョンを管理するための「適切な方法」
だから私はこれを読んだ-- https://wiki.archlinux.org/index.php/Python
そして、このwikiから、Python 2.7.2経由でインストールできることは明らかです。
pacman -S python2
Python2へのシンボリックリンクを作成するのは合理的ですか？
ln -s python2 /usr/bin/python
すぐにpython 3.0に切り替えるとは思わない場合は？または、通常使用しているような複数のpythonバージョンを管理するためのより良い方法はありますか？ Debianシステム（update-alternatives --config python）またはmac os xシステム（python select）？
説明：
- 私が見つけようとしているのは、archlinuxシステムでさまざまなpythonバージョンを管理するための「ベストプラクティス」とは何ですか？
- 私はarchlinuxを初めて使用しますが、ubuntu、debian、mac osxに精通しています。
ほとんどのユニスにはすでに/ usr/bin/pythonがあります。これはシステム内のすべてのパッケージで使用されるPythonバージョンであるため、これを上書きすることはお勧めできません。これを変更すると、パッケージが破損する可能性があります。 Python 2.7パッケージをインストールする場合、実行可能ファイルは/usr/bin/python2.7としてインストールする必要があります（そうでない場合は、Archlinuxが壊れていると主張します）。Python2.7。
Archlinuxは、Python3のデフォルトの実行可能ファイル名が/ usr/bin/python3であるにもかかわらず、Python3に/ usr/bin/pythonを使用するため、少し特別です。これは紛らわしく、バグと見なすことができますが、Python 3を使用する他のArchlinuxスクリプトはほぼ確実に、Python2にそのシンボリックリンクを使用できないことを意味しますもしそうなら壊してください。
したがって、他のユニスでは/ usr/bin/pythonをPython 2.7にシンボリックリンクするのは悪い考えですが、Archlinuxではひどい考えです。代わりに、必要なすべてのバージョンをインストールし、/ usr/bin /pythonX.Xで呼び出します。
このようなシンボリックリンクを作成するべきではないと私は主張します。特に、pythonコードの一部を配布する場合は、ユーザーが/ usr/bin/pythonにpython2またはpython3を持っていると想定しないでください。
スクリプトにpython2が必要な場合は、次を使用してください。
#!/usr/bin/env python2
スクリプトにpython3が必要な場合は、次を使用します。
#!/usr/bin/env python3
このようにして、Pythonを更新してもスクリプトは正常に機能します。また、スクリプトが実際に必要とするバージョンもはるかに明確になります。
Githubには、それを支援する素敵なプロジェクトがあります pyenv 複数のpythonインスタンスを管理するのに役立ちます
他の人が言っているように、短い答えは「これをしないでください、それはあなたのシステムで物事を壊す可能性が高いです」です、しかしあなたが主にPython 2を使うなら、あなたはまだあなたの個人を設定することができますシェルのデフォルト（そしていつでもPython 3）に切り替えるオプションがあります）。これを行うには、最初に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)
ローカルにインストールされたパッケージ（たとえば、pacmanによってインストールされたパッケージではなくpipでインストールしたパッケージ）のみを使用する場合は、環境を作成するときに--system-site-packagesオプションを削除します。
次に、~/.bash_profileまたは~/.profile（または任意のシェル構成ファイル）で、次のように設定します。\
source ~/env/bin/activate
これにより仮想環境がアクティブになり、デフォルトバージョンがPython 2になります。
これにより、シェルで起動されたものがすべて破損する可能性がありますが、シェルから明示的に実行していない限り、破損する可能性はほとんどありません。その時点で、次のコマンドを実行して仮想環境をオフにできます。
deactivate
または単に手動でPython 3を実行します。
これは非常に古い答えかもしれませんが、問題を解決するのに2日かかったので、共有します。
システム内のpythonバージョンを管理して、狂わせることなくさまざまなプロジェクトで作業するための適切な方法は、 pyenv およびそのプラグイン pyenv-virtualenv および pyenv-virtualenvwrapper Henrique Bastosによって このブログ投稿 に説明されています。 pyenvはpythonパッケージであり、まったく同じように実行できるため、この作業方法はkindaプラットフォームに依存しません。 Windows、Linux、MacOSxで。
問題はArchLinuxから始まります。 OSはパックマンバージョンのpyenvを提供していないため、 リリースのインストールセクション で説明されているように、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を適切にインストールし、同じ方法でプラグインを介して管理できます（構文はpyenv [COMMAND] [OTHERSTUFF]であるため）。
私はこの投稿に偶然出くわしました。ネクロバンピングは意図されていませんでしたが、virtualenvsについて誰も言及していないのではないかと思っていました。 ArchLinuxも使用しており、pythonパッケージ virtualenv および virtualenvwrapper を使用して複数のpython環境を作成しています。/usr/bin /内のpython 2またはpython3バイナリを参照して、仮想環境で使用されているpythonバージョンを判別できます。
利点は、仮想環境にインストールされたパッケージが、システムが使用しているpythonを混乱させず、プロジェクト処理を自動化する多くの方法があることです。
いいえ、これを行うためのより良い方法はありません。 pythonシンボリックリンクはPython 3パッケージの一部です。
このリンクを変更しても今のところ何も壊れないと思いますが、将来的には一部のパッケージがそれに依存する可能性があります。