On Mon, Jan 25, 2016 at 9:39 AM, Russel Winder <[email protected]> wrote:
> I am having difficulty making a decision… > > The earlier Python 3 branch is founded on using six. At the time a good > decision. Now however we have agreed that 2.7 is the base version and > thus future rather than six is the better tool for Python 3. This > brings into doubt the python3-port branch as a good base of operations. > > William has done some work changing the python3-port branch, as have I, > all based on the massive previous work. Despite all this effort I > wonder if we have the right base to progress further. Maybe we have and > carry on, but now is the time to stop before much more effort goes in > if this is not the way forward. > > The alternative is to abandon the current python3-port and start again > from default based solely on future. > > Instead of having a separate branch, let us work solely on default, > turning it first into a Python 2.7 only thing using futurize to prepare > the ground. This is really an extension of what is currently happening > of course, but with a turbo charger. Let us insist that the SCons > default branch is "futurize -1" with all __future__ imports in place, > so that all Python 2.7 code is using Python 3 semantics where > possible. > I think this is reasonable, but I don't know what effort has been made prior to now. > > This can happen within the current infrastructure effectively > unchanged. Obviously all CI should be green with each changeset. I > suspect it will not run under Python 3 in this form. > > When this is done, we can add the "futurize -2" with the dependency on > future, obtained not by vendorizing but by package management install. > This should leave the Python 2.7 CI still green – assuming all the CI > servers have future installed. (With Codeship and Drone this is handled > by using a requirements.txt file in the usual pip-ish way.) Then the > work of getting a Python 3 CI green can happen, with the Python 2.7 CI > always green. > I'd prefer to make a solid attempt to not have a dependency of future if possible. Once it is added, chances are it will never be refactored out... > > Of course even though the Python 2.7 tests are red, and the Python 3 > tests do not run, python3-port on Python 3.5 and 2.7 actually works. > This is the opposite side of the coin, why change strategy now? > Does SCons appear to function in the branch? I haven't tried actually compiling anything? There aren't that many 2.7 tests failing. It's less than 50 on my Linux configuration, and I have most of the tools setup. Not sure what the other platforms look like... > > > -- > Russel. > > ============================================================================= > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
