[Scons-dev] Why we need to release separate SCons3 for Python 3

[William Deegan]

Anatoly,

Lots of thoughtful comments below. I have a few items to add.

On Feb 23, 2013, at 2:24 AM, anatoly techtonik <techtonik at gmail.com> wrote:


> On Sat, Feb 23, 2013 at 2:48 AM, Gary Oberbrunner <garyo at oberbrunner.com> wrote:

> As long as existing users stay with Python 2 (2.7 specifically), they should not have to do anything.

> 

> Users not always have control over the version of Python installed. IIRC, Fedora already comes with Python 3 installed as `python` binary as default, and in Windows the latest installed wins. The users are not developers, do there is not guarantee that they know if they are staying with Python 2 or 3. 

> 

> After a SConstruct is ported to Python 3, users who stay with Python 2.7 will have to do something. There are no 'trained people', so let's forget about it - the greatest asset of SCons is its simplicity - it should guide users if somethings is not right. If SConstruct is ported, then scons 2 should give a notice that 'SConstruct is ported to Python 3, you need scons3 to run this file'.

> 

> In long term, the scons will be moved to scons 3.0.x alpha, but for the time of migration it will be much easier for everybody to use scons3 explicitly. Now that SCons is able to run from the source checkout - it can be good to recommend people to include scripts directly in their codebase. We can make it even as simple as checkout and copy.

> 

> 

> So, to make people switch, we need the following guard mechanizm:

> 1. scons3 binary is a must for all work being done in Python 3 compatibility

> 2. obligatory #!/usr/bin/env python3 or python2 headers in both scons binaries

>     (need to test if it works)


This is not viable for many system installed pythons. Especially any older OS's (Centos 4,5,6 probably fall in this category).
Also on win32 systems this won't help.
Perhaps a different launch script per python version so it will clearly state the reason for not running if you try to launch scons2 with python3 or vice versa.



> 3. obligatory #!/usr/bin/env scons3 in SConstruct files that are already ported to Python

>     (this should be checked by scons 2 binary also, the string can be different)

> 


I agree there should be a way to assert that the SConstruct logic is python2 or 3 explicitly.
And perhaps in keeping with our deprecation cycle, the default should be to assume only python2 compatibility unless explicitly stated otherwise in the SConstruct.
And probably worthwhile wrapping the SContruct processing logic to catch the SyntaxError if that's possible, and indicate it could be a python2/3 issue..



> Also:

> 1. clear migration path instructions on front wiki and site pages with defined communication channel


I don't really understand what the following points is, can you clarify?



> 2. restored tracker and roadmap for public process visibility =(

>     (i am patching Roundup to make it an experimental tool for these works, but things are moving slowly - Google and Launchpad logins the weakest point ATM, the roadmap page should also be a great asset for core Python development)

> 3. split all the above into roadmap items and start weekly (code/doc/blog) sprints 

>     (the roadmap should be visually appealing)



Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130223/1518f1b9/attachment.htm>