Title: building with 2to3 generates wrong import paths because build_ext is run after build_py
Type: behavior Stage: needs patch
Components: Distutils, Distutils2 Versions: Python 3.3, Python 3.2, 3rd party
Status: open Resolution:
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: Arfrever, alexis, eric.araujo, simohe, tarek
Priority: normal Keywords: easy

Created on 2011-11-01 21:32 by simohe, last changed 2013-03-11 04:35 by eric.araujo.

Messages (5)
msg146808 - (view) Author: simohe (simohe) Date: 2011-11-01 21:32
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.
msg146944 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-03 16:33
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?
msg146979 - (view) Author: simohe (simohe) Date: 2011-11-03 20:51
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:

short summary:

build.sub_commands in should list "build_ext" before "build_py".
lib2to3.fixes.fix_import will write global instead of local import statements else.
msg148044 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-21 14:35
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.
msg183926 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-03-11 04:35
For the record this is caused by #17393
Date User Action Args
2013-03-11 04:35:01eric.araujosetmessages: + msg183926
2011-11-21 14:35:24eric.araujosetassignee: tarek -> eric.araujo
type: behavior
components: + Distutils2, - 2to3 (2.x to 3.x conversion tool)
versions: + 3rd party, Python 3.2, Python 3.3
keywords: + easy
nosy: + alexis

messages: + msg148044
stage: needs patch
2011-11-05 22:42:51Arfreversetnosy: + Arfrever
2011-11-03 20:51:34simohesetnosy: + tarek
messages: + msg146979

assignee: tarek
components: + Distutils, - Build
2011-11-03 16:33:50eric.araujosetnosy: + eric.araujo
messages: + msg146944
2011-11-01 21:32:12simohecreate