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

[parafoxia]

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!

[henryiii]

I can easily reproduce with the following lines from any package - build itself included:

$ docker run --rm -v $PWD:/pkg -w /pkg -it python:3.10 bash
$ python -m pip install build
$ python -m build
...
* Installing packages in isolated environment... (wheel)
/tmp/build-env-l66jf453/bin/python: Error while finding module specification for 'pip' (AttributeError: module '__main__' has no attribute '__file__')

[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 #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.

[joelbarranteswins]

I found this solution on the other issue #426 (comment)

[parafoxia]

@joelbarranteswins Your solution didn't work for me, as I got a different error:

* Getting dependencies for sdist...
running egg_info
writing manifest file 'chatto.egg-info/SOURCES.txt'

ERROR Missing dependencies:
        wheel

HOWEVER, I tried running python -m build normally, and it magically worked. I then tried to run it on my Github Action again, and it also magically now works. I'm really not sure why that is (because it worked on GH, the --no-isolation doesn't have an effect). I'm gonna leave this issue open in case the maintainers want to look into why this might have happened -- I can answer further questions on the matter.

[parafoxia]

My only real guess is that Pip was having some sort of issue connecting to what it needed to connect to and didn't know what to do (whether that be my internet or whatever), but I'm not amazingly confident in that hypothesis. I only mention it cos my internet was acting up a little before this all happened, so there is a chance this may have been caused by that.

[henryiii]

It seems like it's working again, maybe a PyPI issue? Can you retry?

[parafoxia]

Yeah it's all working fine again. My best guess is a PyPI or otherwise pip-related issue.

[henryiii]

Yes, it was broken on both 3.10.0 and 3.10.1, and now it's working, and there were no releases of anything, so that's my current guess.

[layday]

This appears to have been caused by setuptools 60.3.0 which has been yanked. Ref: pypa/setuptools#3002.

[henryiii]

Hmm, okay, that does make sense, though I thought someone said they were using setuptools 58, but I bet it was using the latest one later in the process. Good to know! I would like to continue to work on our error reporting, though. We still show the detailed traceback inside build when a system call fails, but no one needs to see that - we just need to know what system call failed.

[layday]

Well, it's useful knowing where the subprocess was started, otherwise you'd have to guess that the subprocess call is made by build.

[henryiii]

It could (and should) print out something identifying which call was made, but you don't need a whole traceback. Users are copying in the traceback, but the real error comes from the subprocess, not the traceback in build.

[layday]

Yeah, if we can condense it, that would be nice, but it might be difficult to identify the origin from the tb.

[parafoxia]

Well, it's useful knowing where the subprocess was started, otherwise you'd have to guess that the subprocess call is made by build.

It was made by build. Does the build call use the latest setuptools version regardless of the one that's installed? I presumed as such from your comment, but seen as there's a discussion I'd double check.

[henryiii]

Build runs PEP 517 build, which uses the PEP 518 requirements. Assuming you had a normal requires = ["setuptools", "wheel"], then that will always be the latest setuptools, regaurdless of what is installed.

The side discussion you quoted was just about subprocess calls and showing the traceback - I don't think seeing a traceback of build's internals is helpful when something it calls breaks - you'd rather see why the thing it calls breaks, along with a tiny bit of information about what was called. Basically, if you know something might fail, you should not show a traceback - tracebacks are for unexpected failures.

[parafoxia]

Aah right, slightly misinterpreted your comment -- thanks for the clarification though!

As for the error thing, yeah I agree. It would prevent further confusion like this, provided as layday said the info could be extracted from the traceback.

[layday]

I suppose we could just rewrap subprocess errors wherever we call subprocess in build and not worry about subprocesses from other packages.

[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.

[coder-nd-001]

While installing model face the problem pip error

[aaronkanzer]

Seeing this error this AM as well...