building wheel from sdist fails #320
Comments
|
Do you have python3-devel installed? |
|
Yes I do. I'm able to reproduce this at will on both CentOS 7.7 and Mac OS X 10.15.3 (Catalina) with Python 3.6, 3.7, and 3.8. Here's the full set of commands and output that I used on CentOS 7.7 with Python 3.6. Note: I'm able to compile dozens of other Python packages using the same command both with and without Cython. In the output below, you'll see that it compiles fine, then tries to run bdist_wheel (search for "running bdist_wheel") and then tries to compile again and that fails. Note the error at the end. That should not point at a UnixCCompiler object - it should be a string. That string gets used as a key to a dict and, in the case of running on CentOS, should be "unix". If it were, this would work. What seems to be happening is that (somehow) your setup.py file is passing a compiler object back to a method to create a new compiler object. I've not seen any other Cython package we build using this command do that so I don't know why that is happening. |
|
I think I may have found it. In your setup.py, you're short-circuiting the call to super().initialize_options() here. That means you're forcing subsequent commands to inherit variables that they expect to set for themselves (like self.compiler, which is what is causing the build failure). The same applies to finalize_options(). If you simply want to avoid your options from being reset, you could move the 4 lines that set your options into the body of that if and always call super()initialize_options(). I'm not sure why you're avoiding those calls to super().foo() in initialize_options() and finalize_options(), but those seem to be what is messing up builds with multiple commands on the same line. |
|
Hm. Good catch. I'll take a look and see if this hack is still necessary. |
|
I know this is old, but it still fails. Any luck deciding on whether that hack was still required? As it stands, uvloop still can't be built from sdist 😦 |
|
I think we can drop this hack now, as |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PYTHONASYNCIODEBUGin env?: N/AWhat I did:
pip wheel --global-option build_ext --global-option --inplace uvloop==0.14.0What I expected:
The command would build uvloop and bundle it as a wheel for me.
What I saw:
The command fails with
error: don't know how to compile C/C++ code on platform 'posix' with '<distutils.unixccompiler.UnixCCompiler object at 0x7f054bc1fa10>' compilerafter build_ext runs (e.g. during the processing of bdist_wheel).The (heavily) snipped output from the above command is:
Other observations:
The pip wheel command essentially downloads your sdist, unwinds it, cd's to that directory, and runs
python setup.py build_ext --inplace bdist_wheelThis mimics your make file other than the fact that build_ext and bdist_wheel are on one command line.If I manually run
python setup.py build_ext --inplace && python setup.py bdist_wheel, then the wheel is successfully built. I can't tell exactly how, but it seems like something is building the extension in bdist_wheel instead of simply inheriting what was build by build_ext. That, in turn, is triggering what may be a latent distutils issue that I documented here.The text was updated successfully, but these errors were encountered: