We need build_ext before build_py. Otherwise, when 2to3 is called (in build_py), it will not find ext modules, thinking that those modules are global and, consequently, making a mess, now that all module imports are global.

Hello and thanks for the report.

> We need build_ext before build_py. Otherwise, when 2to3 is called (in build_py),
> it will not find ext modules,
Why is 2to3 interested in extension modules?  2to3 converts Python code, extension modules are written in C or C++.

> thinking that those modules are global
I don’t understand what you mean.

Can you give me a Python or shell script to reproduce the error or a full description of what you did, what you expected and what went wrong?

fix_imports rewrites the import statements to local or global. When a python module loads a local extension module, this import statement should be converted to a local import (from . import extensionmodule). But when the extension module is not built yet, fix_imports does not find them (no file named extenstionmodule.[so|sl]). So it suggests a global import (import extensionmodule).


The original comment is a slightly modified version of this here:
http://selenic.com/hg/file/afc02adf4ded/contrib/setup3k.py#l223


short summary:

build.sub_commands in distutils.command.build should list "build_ext" before "build_py".
lib2to3.fixes.fix_import will write global instead of local import statements else.

Ah, thanks for clarifying, I didn’t understand what you meant with local/global but now I see it’s about absolute imports and explicit relative imports.  (I don’t remember ever reading that terminology before looking at fix_import.)

I’m adding the “easy” keyword because it should not be too hard to write tests for this, with the examples and helpers we already have in the test suite and given that I’m available for help.

For the record this is caused by #17393