Automatic 2to3 conversion when installing packages

Alex Grönholm avatarAlex Grönholm created an issue

Maybe we should come up with a mechanism to allow authors to provide a single source package for both 2.x and 3.x. Automatic 2to3 conversion would then take place on installation or egg packaging. This could be implemented as an additional keyword argument to setup().

Comments (16)

  1. Lennart Regebro

    This is most easily done by making versions of the build commands that automatically invoke 2to3 if run under Python 3. I've done this for the Python 3 port for zope.interface, and attached is an untested version that is more generic for setuptools. It could probably be put into the normal setuptools/command structure instead of being in a separate file, unless there is some reason for this I don't remember anymore.

  2. Tarek Ziadé

    I think it would be better done during installation because it's not easy to release two different source distributions.

    And having two pre-created source trees in the same distribution can lead to confusion imho

  3. Alex Grönholm

    Now that I think about it, running 2to3 on installation makes a lot of sense, but the installer needs to know that it's necessary to do so -- how do we specify that? I'm unsure of whether support should be added for 3to2, as it is a third party tool. Also, the actual 2to3 API is unstable so I suppose we have to run it as a shell command.

  4. Martin von Löwis

    Please take a look at http://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/setuptools-0.7a1dev-r66.diff. In build_py.py, I add an option with_2to3; this integrates running 2to3 at build time, when run under Python 3. Packages that desire this option need to specify it in their setup.py, e.g. http://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/zc.lockfile.diff.

    I don't see the need to run 2to3 as an external tool; for 3.1.x, the API provided by distutils will not change. I would also advise against running 2to3 at installation time; 2to3 can take quite a while, and there is no point in doing the same conversion over and over again.

  5. Alex Grönholm

    Quoted straight from the Python 3.1.1 docs on 2to3:

    The lib2to3 API should be considered unstable and may change drastically in the future.

    Where did you get your information saying that the 2to3 API will not change?

    Still, on the build vs install time issue, I'm with you on the choice of build time conversion.

  6. Tarek Ziadé

    That's awesome !

    I suppose 2.3 is not supported anymore ? if 2.4 is still supported that will make a lot of people happy to have py 3 support in the next Distribute 0.6 release.

    If so, would you mind merging that clone into the 0.6-maintenance ?

  7. Martin von Löwis

    I have tested it with 2.4, and it seems to work fine, so I have pushed the changes.

    2.3 apparently isn't supported anymore at least since 8ae2dde828d6, which introduces usage of the subprocess module. For the 3.x compatibility itself, it wouldn't be necessary to give up 2.3 compatibility.

  8. Tarek Ziadé

    Thanks for the push that's a great step forward.

    At this stage, if the only 2.3 compatibility problem is the subprocess usage, I can go ahead and fix this, unless this would require extra work for 2to3 to work fine everywhere.

    If it does require more work, I propose to drop its support as there doesn't seem to be a strong interest in 2.3 support for the next release.

  9. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.