Issue building a package using `python -m build` (pip error)

Problem description

So I’m not 100% what’s happening here as it’s only just started to happen. It happens on all versions of Pip, and even on code where it worked just a few days ago, so I’m completely stumped. I’ve also tried it on both Python 3.9 and 3.10 and getting these errors, and even my GitHub Actions workflow is having the same problem. I was using setuptools 58.1, but updating to 60.3 makes no difference.

Whenever I try to run python -m build, everything works fine until it tries to build a wheel. The tar archive builds okay, and appears to have all the correct files in it. This is the output/error in full:

* Building wheel from sdist
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (setuptools>=42, wheel)
* Getting dependencies for wheel...
running egg_info
warning: no previously-included files matching '*.py[cod]' found anywhere in distribution
writing manifest file 'chatto.egg-info/SOURCES.txt'
* Installing packages in isolated environment... (wheel)
/tmp/build-env-8qhq7gxo/bin/python: Error while finding module specification for 'pip' (AttributeError: module '__main__' has no attribute '__file__')

Traceback (most recent call last):
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/__main__.py", line 372, in main
    built = build_call(
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/__main__.py", line 242, in build_package_via_sdist
    out = _build(isolation, builder, outdir, distribution, config_settings, skip_dependency_check)
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/__main__.py", line 140, in _build
    return _build_in_isolated_env(builder, outdir, distribution, config_settings)
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/__main__.py", line 110, in _build_in_isolated_env
    env.install(builder.get_requires_for_build(distribution))
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/env.py", line 211, in install
    _subprocess(cmd)
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/env.py", line 81, in _subprocess
    raise e
  File "/home/parafoxia/Programs/Projects/chatto/.venv/lib/python3.10/site-packages/build/env.py", line 78, in _subprocess
    subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "/usr/local/lib/python3.10/subprocess.py", line 420, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/local/lib/python3.10/subprocess.py", line 524, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/tmp/build-env-8qhq7gxo/bin/python', '-Im', 'pip', 'install', '--use-pep517', '--no-warn-script-location', '-r', '/tmp/build-reqs-vohv2_qf.txt']' returned non-zero exit status 1.

ERROR Command '['/tmp/build-env-8qhq7gxo/bin/python', '-Im', 'pip', 'install', '--use-pep517', '--no-warn-script-location', '-r', '/tmp/build-reqs-vohv2_qf.txt']' returned non-zero exit status 1.

I wish I had more of an idea or a starting point but to be honest I’m completely at a loss, and can’t find anything exactly the same around. I’ve looked at a few other issues with the same problems and none of the solutions work, but there may be some I missed.

Thanks in advance for your help!

[joelbarranteswins]

Hello guys, I’m not really sure what it’s really happening here. I’m getting this error however I’m using python=3.96, venv on windows 10 and I’m trying compile my own package.

hope your answer this could be the same issue from https://github.com/pypa/build/issues/426

Traceback (most recent call last):
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\__main__.py", line 372, in main
    built = build_call(
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\__main__.py", line 242, in build_package_via_sdist
    out = _build(isolation, builder, outdir, distribution, config_settings, skip_dependency_check)
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\__main__.py", line 140, in _build
    return _build_in_isolated_env(builder, outdir, distribution, config_settings)
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\__main__.py", line 110, in _build_in_isolated_env
    env.install(builder.get_requires_for_build(distribution))
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\env.py", line 211, in install
    _subprocess(cmd)
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\env.py", line 81, in _subprocess
    raise e
  File "C:\Users\joel_\OneDrive\Documentos\GitLab\darit\cli\.venv\lib\site-packages\build\env.py", line 78, in _subprocess
    subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "C:\Users\joel_\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 424, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "C:\Users\joel_\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['C:\\Users\\joel_\\AppData\\Local\\Temp\\build-env-xzabxgoo\\Scripts\\python.exe', '-Im', 'pip', 'install', '--use-pep517', '--no-warn-script-location', '-r', 'C:\\Users\\joel_\\AppData\\Local\\Temp\\build-reqs-lp2bxm5b.txt']' returned non-zero exit status 1.

ERROR Command '['C:\\Users\\joel_\\AppData\\Local\\Temp\\build-env-xzabxgoo\\Scripts\\python.exe', '-Im', 'pip', 'install', '--use-pep517', '--no-warn-script-location', '-r', 'C:\\Users\\joel_\\AppData\\Local\\Temp\\build-reqs-lp2bxm5b.txt']' returned non-zero exit status 1.

[henryiii]

Yes, we’d have a custom error if a subprocess call fails, rather than just letting a traceback bubble up. It would only be on subprocess calls we know might fail - if a failure is unexpected, then a traceback is fine / correct.