Any way to create a stdlib style venv instead of virtualenv style?

[wimglenn]

I wonder if it is possible to ask uv venv for a stdlib venv style env instead of a virtualenv style one?

The latter registers a new meta_path importer which I don't really want in my envs (it makes every import statement a little bit slower).

$ uv venv -q .venv1
$ python3 -m venv .venv2
$ .venv1/bin/python3 -c 'import sys; print(sys.meta_path)'
[<_virtualenv._Finder object at 0x7ffff6f99c10>, <class '_frozen_importlib.BuiltinImporter'>, <class '_frozen_importlib.FrozenImporter'>, <class '_frozen_importlib_external.PathFinder'>]
$ .venv2/bin/python3 -c 'import sys; print(sys.meta_path)'
[<class '_frozen_importlib.BuiltinImporter'>, <class '_frozen_importlib.FrozenImporter'>, <class '_frozen_importlib_external.PathFinder'>]

Thanks!

[mitsuhiko]

While it's true to that it makes the imports a tiny bit slower, I wonder how the stdlib avoids this finder. It exists to solve specific issues with distutils and setuptools.

[wimglenn]

Maybe they don't? Not sure.
My env is externally managed, and it's Python 3.12+ so the stdlib distutils is gone.
I don't have setuptools/distutils installed in the env so there is no issue for the finder to solve (but still the check happens on every import statement).

[mitsuhiko]

I have been trying to get rid of this finder in rye for a while and I have not found a good alternative. You can find some history and related links to it: pypa/virtualenv#1688

I really wish this hack was not necessary but I'm not aware of a much better one. It might be interesting to see if that .pth can be placed only when setuptools or distutils are in the venv.

I really don't like giving the user a flag to shoot themselves in the foot.