build: RuntimeError: Virtual environment creation failed, executable /usr/local/bin/python missing

When running

python3 -m build --sdist --wheel .

on Mac OS, I’m getting

Traceback (most recent call last):
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/__main__.py", line 210, in <module>
    main(sys.argv[1:], 'python -m build')
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/__main__.py", line 202, in main
    build_package(args.srcdir, outdir, distributions, config_settings, not args.no_isolation, args.skip_dependencies)
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/__main__.py", line 81, in build_package
    _build_in_isolated_env(builder, outdir, distributions)
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/__main__.py", line 45, in _build_in_isolated_env
    with IsolatedEnvBuilder() as env:
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/env.py", line 55, in __enter__
    executable, pip_executable = _create_isolated_env(self._path)
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/env.py", line 171, in _create_isolated_env
    executable = _find_executable(path)
  File "/Users/nschloe/Library/Python/3.8/lib/python/site-packages/build/env.py", line 208, in _find_executable
    raise RuntimeError('Virtual environment creation failed, executable {} missing'.format(executable))
RuntimeError: Virtual environment creation failed, executable /usr/local/bin/python missing

Not sure at all whe it would be looking for python in /usr/local. Any idea what’s going wrong?

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 35 (21 by maintainers)

Most upvoted comments

I mentioned that as a possibility earlier. I do think it’s the wrong way to approach altering the venv scheme. If a different scheme is sought for venvs, a new entry should be added to the preferred scheme dict, for venvs. get_preferred_scheme is supposed to be the single source of truth for schemes by install type. And because it bears repeating: they should absolutely not be varying the schemes depending on the active prefix. I’m lukewarm to the idea of relying on an extension to the venv spec that has scarcely been discussed and has not been merged into CPython. But if it’s gonna get us out of this bind, I suppose we could look for venv in the scheme names, like we do with the framework prefix for Apple’s Python. Or we could recommend that people use virtualenv, like Bernat has suggested.

layday on Jan 20, 2022

A workaround would be go install build[virtualenv], I think that would not have this issue 🤔

gaborbernat on Jan 20, 2022

~~@gaborbernat Can we not grab the Python executable path from virtualenv directly?~~

Wait, this is the stdlib venv… so something else is going on.

Oh right, of course, the venv module doesn’t use sysconfig, so deadsnakes would need to patch venv if they are using an incompatible default scheme.

Please report this to deadsnakes.

layday on Jan 19, 2022