At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote:
On Tue, Apr 21, 2009 at 15:03, P.J. Eby <p...@telecommunity.com> wrote:
> python2 setup.py 2to3 test
Well, yes, but it should be
python 3 setup.py 2to3 test
Otherwise it can't reasonably have any idea of which python to use.
Why not? The 2to3 command could simply take an option for the
python3 executable, and be set from the standard config files (e.g. setup.cfg).
And when you run it with python3, the 2to3 command isn't needed, as
the 2to3 step can be automatically inserted through version detection.
Um... I'm still not following you. You sound like you're describing
something very different from what I outlined.
In fact, this is exactly what I'm doing for zope.interface, as
explained. For zope.interface, you run
python2.5 setup.py test
and it will test it with python2.5 You run
python3.0 setup.py test
and it will do exactly what you say: copy the files to build, run
2to3, and then run the test on that in-place.
python3.0 setup.py install
will copy the files to build, run 2to3 and then install it.
Right -- but this is totally *not* what I'm saying. Because the
strategy that I outlined doesn't require setuptools to be ported to
python 3 first.
Yes. That's is exactly what I'm trying to achieve. And I aim to extend
setuptools with build_2to3 and test_2to3 commands to do exactly that.
But to do that I need a good setuptools distribution that supports
Python3.
No, you don't. You only need one command, implemented as a plugin
for the Python2 version of setuptools, and you drive everything from python2.
Once you get to the point where setuptools is ported enough to be
able to have the Python3 version actually run its tests without
crashing, you can go self-hosted. But before that point, you need
Python2 as the bootstrap/host environment for the build process.
It explains why the test cases
could run even though setuptools still couldn't install itself. I
thought it was badly tested, now I know it's by design.
No, it's also badly tested; that's kind of inherited from the
distutils. And by the time I added the 'sandbox' virtualization
tool, there was already tons of stuff that wasn't tested, such that
it didn't seem worth it to do something else.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
