Automatic 2to3 conversion when installing packages

Create issue
Issue #31 resolved
Alex 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. Alex Grönholm reporter

    There is still the issue of whether to do this during egg packaging or installation. What are your opinions?

  3. Tarek Ziadé repo owner

    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

  4. Alex Grönholm reporter

    I was actually thinking about running 2to3 automatically when creating an egg for py3k.

  5. Alex Grönholm reporter

    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.

  6. Martin von Löwis

    Please take a look at In, 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, e.g.

    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.

  7. Alex Grönholm reporter

    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.

  8. Alex Grönholm reporter

    Ok, I didn't know who you were, sorry. Apparently the Python docs need some updating. If the API is indeed stable, then I have no issues with this.

  9. Martin von Löwis

    I now have a clone of distribute which runs 2to3 transparently in build_py at

    @Benjamin: I think we also need to be very careful about preserving stability of the basic 2to3 API, which is primarily the RefactoringTool.refactor method; we absolutely must preserve compatibility for this within the 3.1 branch.

    @Alex: Basically, the API is stable because I, as a core committer, promise it to be stable.

  10. Tarek Ziadé repo owner

    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 ?

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

  12. Tarek Ziadé repo owner

    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.

  13. Log in to comment