Executive summary: I have catch 22 problems in finishing the setuptools port to Python 3, and unless somebody can come up with alternatives, I may rip out setuptools dependency on itself completely, and only depend on distutils.
I have as you know ported setuptools to Python 3. I'm in the process of trying to fix and clean up that porting so that it can be merged into trunk, but there is one obstacle left, and that's the question of installing. Currently there are several ways to install setuptools: 1) Run ez_install.py 2) Download / check-out source and run python setup.py install. 3) Download the correct egg and install that (which always confuses me, I usually fail, and end up doing 2) instead). Setuptools also helps with running tests by 4) python setup.py test Currently for the Python 3 version, I've made a script that copies the source tree and runs 2to3 on it. Then you can use that new tree to run tests, install, make eggs and releases etc. The problems with this is: a) The script is made for my computer only. It wouldn't work on Windows, and it requires you to have lib2to3 checked out in a particular place (although I think that's only if you use 3.0.0, and not 3.0.1, but I haven't tested). b) It's slow, as it copies all files, even those who hasn't changed when you fixed a bug. Making a script that only copies the changed files and runs 2to3 on them is possible, but I'd like not too, it takes time and is likely to break. It seems like a waste. Obviously, this is exactly the things distutils are meant to solve. And indeed, distutils in Python 3 has a command called build_2to3 which solves exactly these problems. And indeed, this is the technique I've used for the Python 3 branch of zope.interfaces. There I just run setup.py install, and if I'm doing that under Python 3, it will first run 2to3 on the code before installing. Same thing with running setup.py test. It will sync changes to build/, run 2to3 on changed files and then run the tests in build. It makes porting to Python 3 much easier, and it makes installing from source painless. So why don't I use that for setuptools? Well, because: c) The setup of setuptools requires setuptools. So to be able to do the 2to3 conversion in the setup, I need to first convert the source with 2to3. Yes, catch 22. I've tried to get around this problem, but failed. Solutions I tried was: I) Fall back to distutils if setuptools can't be imported. This means that I can with some effort make a setup that will work under Python 3 and install setuptools under Python 3. Problem solved? No. Because running setup.py again will just mean that it tries to import setuptools from the local Python2 location, and it will fail. So in this case I can't run tests of build eggs for setuptool. II) Moving the source into a src directory. This means that when setup.py runs, it will use the version of setuptools installed under I), and building eggs etc is possible (I think, I haven't tested that the eggs are correct). Problem solved? No, because you still can't test it. Which leads us to problem d: d) When running the tests, the setuptools module will already be imported. But it will have imported the one in site-packages, *not* the one in src, and it will therefore test the one in site-packages. And that one doesn't have the api_tests.txt copied in, so that will fail, and e) even if api_tests.txt was copied, this would mean you had to install setuptools before you test it, which is daft. I don't have a good solution to this, unless we can drop setuptools dependency on setuptools completely, and just use plain distutils for installing and testing setuptools. This will mean no more setuptools source eggs, but then I don't see the purpose of those, really. Arguments for not doing this and alternative solutions are highly welcome. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig