At 10:14 PM 3/11/2009 +0100, Lennart Regebro wrote:
On Wed, Mar 11, 2009 at 21:47, P.J. Eby <p...@telecommunity.com> wrote:
> Why not just invoke:
>
> python3 -m unittest somemodule.somesuite
>
> Then there are no dependencies on distutils or setuptools.
Because it needs to run 2to3 on the code first.
That's what the build_py option (to run 2to3 on the copied .py files)
would be for.
Also, python3 setup.py install will fail, becuase the installation
depends on setuptools, and then I need to do build_py_2to3 on the
code, which isn't going to work if the install program depends on
setuptools, as it hasn't been converted to Python3 yet.
I think we must be entirely misunderstanding each other here. I
don't see where the problem is, exactly. Assuming that 2to3 can
convert some version of 2.x-compatible setuptools to a valid
3.x-compatible version, self-dependency would not be an
issue. Likewise, using 2.x to manage the process of converting and
then invoking tests in 3.x on the converted version, doesn't seem
like a problem to me either. You just run separate interpreters for
anything that needs 3.x to run, while leaving the primary build
operations in 2.x.
If you're trying to say that you want a build process that can run
without there being a 2.x interpreter present, but starts with the
same source code base, I don't see how that's possible without having
some sort of alternative setup3.py or other .py scripts present, to
do the conversion.
The alternative, which seems less likely, is to rewrite setuptools to
run under Python 2.3, 2.4, 2.5, 2.6 and 3.0 without using 2to3. :-D
Or of course, continue having a separate source distribution for
Python 3 and a bit complicated development process, which is
survivable, but I don't think it's a good long term strategy.
You can have a single source distribution, you'll just need a
different way to access the 3.x stuff from the 2.x stuff, like a
'setup3.py' or something. (This might be a useful idea in general,
not just for setuptools.)
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
