Virtualenv: virtualenvのスクリプトに標準ライブラリスクリプトを含める

これは、pyenv rehashを実行した後も発生しますか？

pyenvの再ハッシュの前または後に実行すると、shimは何を実行しますか？

これはpyenvと関係があると思います。

これは、pyenv rehashを実行した後も発生しますか？

はい。

pyenvの再ハッシュの前または後に実行すると、shimは何を実行しますか？

$＃ 2to3を含むaptパッケージがインストールされていないsystem Pythonが選択されているため、

pyenv: 2to3: command not found

The `2to3' command exists in these Python versions:
<list>

両方の場合において。

これはpyenvと関係があると思います。

pyenvは関係ありません。 予想される動作は、2番目のwhichがpythonの場合と同様に、 virtualenvのシムを返すことでした。 バグは、 virtualenvが作成しないことです。 （これは明らかだと思いました。おそらくそうではありません。）

ああ、わかりました...アクティベーション後のPATH何ですか？

（私は今これを再現できるマシンを使用していません）

(test) vmuser<strong i="5">@ubuntuvm</strong>:~$ echo $PATH
/home/vmuser/test/bin:/home/vmuser/.rbenv/shims:/home/vmuser/.rbenv/bin:/home/vmuser/.pyenv/shims:/home/vmuser/.pyenv/bin:/home/vmuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/vmuser/.rvm/bin
(test) vmuser<strong i="6">@ubuntuvm</strong>:~$ ls /home/vmuser/test/bin
activate       activate_this.py  pip     python3
activate.csh   activate.xsh      pip3    python3.6
activate.fish  easy_install      pip3.6  python-config
activate.ps1   easy_install-3.6  python  wheel

回避策として、virtualenv内で同等の機能を備えたpython -m lib2to3を使用できます。

/ccその他の@pypa/ virtualenv-コミッターは、スクリプトを作成するときに標準ライブラリからvirtualenvにスクリプトを追加することをお勧めします。

私は相反する。

私は-0.5です。 これまで問題としてフラグが立てられていなかったのは余分な混乱なので、必要になることはめったにないと思います。 Python2がEOLに近づいていることがここで違いを生むとは思いません。 余分なスクリプトは、Windowsの非仮想環境でもPATHにないため、それらが存在するという期待が普遍的であるとは限りません。

これは一般的なアプローチとして機能するはずだと思います。 ホスト環境のすべてのアプリケーションは、仮想環境レベルで利用できる必要があります。

Python2がEOLに近づいていることがここで違いを生むとは思いません。

+1

それはここでも私の関心事ではありません。 :)

追加のスクリプトは、Windowsの非仮想環境でもPATHにはありません

おー。 これらはScripts/ディレクトリにありませんか？ 私の理解では、現在のpython.orgインストーラーはそのディレクトリをPATHに追加するため、実行できます。

ホスト環境のすべてのアプリケーションは、仮想環境レベルで利用できる必要があります。

ええと...「アプリケーション」はここでは少し曖昧です-あなたはスクリプトまたは何か他のものを参照していますか？ 意味を明確にしていただけませんか？

これを行う場合、とにかくホスト環境からのすべてのスクリプトを含めることについては強い-1であり、標準ライブラリによってサポートされているスクリプトを含めることについては曖昧であることに注意してください。

おー。 これらはScripts/ディレクトリにありませんか？

いいえ、 Scriptsに含まれているのは、インストールされているライブラリ（pip、easy_install、およびベースインストールのwheel）のエントリポイントラッパーだけです。 もう少し詳しく見てみると、 2to3.pyはTools/scriptsにあります（60以上の他のスクリプトがかなり混在しています）が、そのディレクトリはPATHに配置されていません。ユーザーは「PythonをPATHに追加」を選択します。

これを行う場合、とにかくホスト環境からのすべてのスクリプトを含めることについては強い-1であり、標準ライブラリによってサポートされているスクリプトを含めることについては曖昧であることに注意してください。

少なくとも、基本的なインストールよりもPATHに追加するべきではないと私は主張します。 つまり、これを行っても、Windowsでは行いません。

pradyunsgはタイトルを変更しました。virtualenvのbinに標準ライブラリスクリプトを含める/2時間前にvirtualenvのスクリプトに標準ライブラリスクリプトを含める

これはわずかなスコープの変更であることに注意してください。 OPは2to3にのみ特に関心があり、特にvirtualenvをアクティブ化してもシステム2to3がシャドウイングされなかったことに関心がありました。 それが重要かどうかについてはコメントできません（これがWindowsで発生しないと主張したことを考えると、これが問題であると感じるかどうかを言うのに関連するUnixの経験はありません）。 しかし、他にどのようなスクリプトが「標準ライブラリスクリプト」であるかを知らなければ、これが重要なポイントであるかどうかはコメントできません。

うーん、 pyvenvはおそらく別の「標準ライブラリスクリプト」であり、そのシステムバージョンをvirtualenv環境からvenvを実行するバージョンでシャドウイングしたくないと確信しています（これは単に複雑さを引き起こすだけです）実用的なメリットはありません）。

OPは...興味を持っていました...特にvirtualenvをアクティブ化してもシステム2to3がシャドウイングされなかったことに興味がありました。

（このフレーズが私の口に何を入れているのかわかりません。両方の方法で解釈できます。）

わかりやすくするために、 2to3のシムを作成するためにvirtualenvを要求しています。

（元の投稿を期待どおりの動作で編集させてください。省略した場合、混乱が生じます。）

（期待される動作で元の投稿を編集させてください）

終わり。 また、ユーザーがPATHにあると予想した理由も明らかにしました。

このフレーズが私の口に何を入れるのかわかりません

コメントを不当表示して申し訳ありません。説明していただきありがとうございます。 （私はあなたが何を求めているのかを正しく理解したようです、私はそれをひどく言い直しました...）

また、ユーザーがPATH上にあると期待した理由も明らかにしました。

あなたが参照したリンクは少し紛らわしいです。 ユーザーは、信頼できるゼニアルでは機能するが、バイオニックでは機能しないプロセスを持っているようです。 問題がvirtualenvにある場合、なぜそうなるのかは私にはわかりません。 （注：これは余談です-とにかく、virtualenvが2to3.pyをコピーしないのは明らかなので、元の問題がより微妙であっても、有効であるかどうかの議論は有効です）。

2to3のシムを作成するためにvirtualenvを要求しています。

シムを作成することは決してないことに注意してください。 2to3.pyスクリプトをコピーするだけです。 シムが必要な場合（それはpyvenvのことだと思います）、それを処理したのは私たちではありません。

いいえ、スクリプトに含まれているのは、インストールされているライブラリ（pip、easy_install、およびベースインストールのwheel）のエントリポイントラッパーだけです。

Oooooooooooooo。 わかった。

これはわずかなスコープの変更であることに注意してください。

2to3は特別なスノーフレークではないと思います。それを追加すると、誰かが残りを求めてやってくると思います。 これを完全に行うか、まったく行わないかのどちらかです。 途中で立ち往生することは、私たちがここで望んでいることではありません。

（私はモバイルUIが嫌いです）

これは、標準ライブラリに支えられており、標準Linuxインストールの場合はPATHにあるという点で「特別」です。
このようなツールは他にあまりありません。 2to3以外は、 pydoc 、 idle 、 pyvenvのみです。

$ ls ~/.pyenv/versions/3.6.9/bin
2to3          easy_install-3.6  idle3.6  pip3.6  pydoc3.6  python3.6         python3.6m         python-config  virtualenv
2to3-3.6      idle              pip      pydoc   python    python3.6-config  python3.6m-config  pyvenv
easy_install  idle3             pip3     pydoc3  python3   python3.6-gdb.py  python3-config     pyvenv-3.6

（また、すでにリダイレクトされているpython-config ）

ああ、@ native-apiの説明に感謝します！ とても有難い。 これがWindows以外の問題であるという@pfmooreの説明とともに、私の理解に役立ちます。 :)

私はまだそれを含めることについては曖昧です。

2to3以外は、pydoc、idle、pyvenvのみです。

誰がそのリストを選んだのか知りたいです。 具体的にはpyvenvですか？ Ubuntu（Windows上のbash、およびpython3がインストールされたdockerイメージ）には、デフォルトで2to3がないようですが、Python dockerイメージには、前述したものと同じバイナリ（さらに、インストールされたパッケージからのpip、easy_install、wheel）があります。 少し分布に依存しているようです:-(少なくとも関連するバイナリのリストは一貫しているようですが。

ところで、私が上で言ったように、私たちがこの変更を行ったとしても、私はpyvenvを含めないことを強くお勧めします。

Ubuntu（Windowsではbash、python3がインストールされたDockerイメージ）にはデフォルトで2to3がないようです

これは、Ubuntuでは2to3が別のパッケージに移動されるためです。

$ apt-file search 2to3 | grep -E '/2to3[^/]*$'
2to3: /usr/bin/2to3
<...>
python2.7: /usr/bin/2to3-2.7
<...>

「標準のLinuxインストール」とは、ディストリビューションに干渉することなく、PythonのLinuxビルドスクリプトに固有のロジックを意味します。たとえば、ソースからインストールする場合（これはpyenvが行うことです）。

私はこれを取り上げることができ、これに取り組むつもりです。

これは、アクティベーションスクリプトの一部としてpydocを追加するという現在のハックに取って代わることに注意してください。