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

[anatoly techtonik]

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)
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)

Also:
1. clear migration path instructions on front wiki and site pages with
defined communication channel
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)



I completely support the Kenny that all dubious operations should have be
refactored into API, and for that, the API should be easy to document.

I run out of time to meditate more over points above, but it seems rather
complete.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130223/33b10cf3/attachment.htm>