web-dev-qa-db-ja.com

$ PATHの最初にあるにもかかわらず、virtualenvが間違ったpythonを使用する

Virtualenvでpythonがpipによってインストールされたモジュールを見つけられないという問題がありました。

私はそれを絞り込み、virtualenvがアクティブになっているときにpythonを呼び出すと、/usr/bin/pythonではなく/home/liam/dev/.virtualenvs/noots/bin/pythonに到達することがわかりました。

Virtualenvでwhich pythonを使用すると、次のようになります。

/home/liam/dev/.virtualenvs/noots/bin/python

Virtualenvで$PATH変数を検索すると、次のようになります。

bash: /home/liam/dev/.virtualenvs/noots/bin:/home/liam/bin:/home/liam/.local/bin:/home/liam/bin:/home/liam/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory

それでも実際にpythonを実行すると、/usr/bin/pythonに移動します

混乱を避けるために、python3.5を実行すると、正しいディレクトリからpython3.5が取得されます(つまり、/home/liam/dev/.virtualenvs/noots/bin/python3.5

とにかく/home/liam/dev/.virtualenvs/noots/bin/には触れていません。 pythonpython3.5は、どちらもそのディレクトリのpython3にリンクされています。 /home/liam/dev/.virtualenvs/noots/bin/へのトラバースと./python./python3または./python3.5の実行はすべて正常に機能します。

私がvirtualenvwrapperを使用しているのは、それが違いを生む場合ですが、インストールのかなり前に、問題が最近発生したようですvirtualenvvirtualenvwrapper

16
liamhawkins

whichにあるはずのプログラムを入手できない場合は、プラットフォームエグゼキューターよりもチェーンを上に調べる必要があります。シェルには通常、コマンドにエイリアスを付ける方法があり、ほとんどのユニキシシェルでは、aliasと入力するだけで、どのコマンドが再マッピングされたかを確認できます。次に、シェルの構成ファイルに移動してエイリアスを削除するだけです。

時々、人々はpythonをエイリアスして、どのpythonを使用すべきか)を整理しようとします。しかし、通常、他のより良い方法があります。私のLinuxマシンでは、例えばpython3はパスに含まれていますが、実際に使用しているpythonへのシンボリックリンクです。

td@mintyfresh ~ $ which python3
/usr/bin/python3
td@mintyfresh ~ $ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Feb 17  2016 /usr/bin/python3 -> python3.4
td@mintyfresh ~ $ 

pythonを実行している非シェルプログラムが私と同じものを取得し、仮想環境が自然に機能するため、これは素晴らしいことです。

4
tdelaney

このactivateスクリプトにwrongVIRTUAL_ENVパスが含まれていたため、私の問題は最近moved virtualenvを使用したプロジェクトを別の場所に移動したことです。

$ cat path_to_your_env/bin/activate

... # some declarations

VIRTUAL_ENV="/path_to_your_env/bin/python"  # <-- THIS LINE
export VIRTUAL_ENV

... # some declarations

これを修正するには、activateスクリプトのVIRTUAL_ENVを更新します。

また、実際のpythonパスにリンクするには、bin/pipの最初の行を修正する必要があるかもしれません。

15
vishes_shell

tdelaney がコメントで示唆されているように、aliasを実行したところ、python/usr/bin/python3.5.bashrcにエイリアスしていたことがわかりました。

私は.bashrcからそのエイリアスを削除し、unalias pythonsource ~/.bashrcを実行して問題は解決しました。

7
liamhawkins

Cygwinでは、/usr/bin/pythonF:\Python27\python.exeにポイントするシンボリックリンクを作成した後でも、まだ問題があります。ここでは、source env/Scripts/activateの後、which python/usr/bin/pythonのままです。

久しぶりに解決策を見つけました。 virtualenv envを使用する代わりに、シンボリックリンクを作成した場合でもvirtualenv -p F:\Python27\python.exe envを使用する必要があります。

1
Gaoping

現在、同じ問題が発生しています。 VirtualenvはWindowsで作成されましたが、今はWSLから実行しようとしています。 virtualenvでは、python.exeをpython3.exeに名前変更しました(WSLにはpython3コマンドしかないため)。 $ PATHでは、virtualenvフォルダーが最初にあり、Pythonのエイリアスはありません。私は受け取ります which python3 /usr/bin/python3/usr/bin/python3 symlink `python3-> python3.6があります。注文の解決には関係ないと思います。

0
Evg