[Scons-dev] 2013+ projects

[Kenny, Jason L]

I would second getting python 3.2 support in. I would favor a 2.7/3.2 move. I understand that this mean people in 2.6 or below will have issue in that the will be stuck with and older version of SCons once that move happens. However I don't see that as an issue as user that choose to say with older system are used to the limitations and bugs that come with older software. That is the risk we all deal with. All tools are broken in some way, and generally get better with newer versions.

I would say that we should target that first, then look at refactoring efforts such as nodes, taskmaster, toolchains, etc.

Jason

-----Original Message-----
From: scons-dev-bounces at scons.org [mailto:scons-dev-bounces at scons.org] On Behalf Of Russel Winder
Sent: Sunday, February 03, 2013 7:13 AM
To: scons-dev at scons.org
Subject: Re: [Scons-dev] 2013+ projects

I thought I would leave it a while to see what others might think about this, but no-one has ventured a view so…

On Sun, 2013-01-27 at 17:26 -0500, Gary Oberbrunner wrote:

> Here's my ideas about what projects are important this year (and into 

> the future -- there's too much here for a year unless we attract some 

> new developers).  I put this out as food for thought, and to start 

> discussion

> -- I'm sure you will have different opinions, things I haven't thought 

> about.  Please chime in!

> 

> SCons projects for 2013

> 

>    - Toolchain revamp

>       - Goals

>          - Toolchain specs with AND/OR/error

>          - Easy install of external tools

>          - Decouple standard tools from core

>          - Allow tools to take args (version, arch, ...) w/o polluting env

>        - Issues

>          - Users need to be able to set up tool chains before SConstruct

>          - Users need to be able to set toolchains for default env

>          - Need reliable exists() method

>          - Don't modify env['PATH'], allow specific path-setting per tool

>             - but make that debuggable

>           - Can we make it back-compatible?

>         - Node cleanup

>       - Speed

>       - Memory

>       - Extensibility

>       - Separate concerns

>          - Filesystem

>          - Dependency info

>          - Signatures

>         - Subst logic

>       - Arrays, strings

>       - Predictability

>       - Orthogonality

>       - Compatibility

>     - Taskmaster

>       - not most important in 2013

>     - Python 3

>       - Compatibility

>       - Options

>          - 2.7+3?

>          - python3 version

>          - ?

>        - How did the ML vote come out?


I would say that making SCons work on 3.2 is the highest priority.
Everything else on the list is either making things nicer or starting a SCons 3. SCons 2.x not working on Python 3 as well as Python 2 flags SCons as legacy software. With Django, NumPy and SciPy already working with Python 3, and many projects looking to work with both, e.g.
Twisted, Any Python entity now acknowledging that Python 3 is the platform of choice.

Before starting the effort to make the code work on both Python 2 and Python 3, we need to get rid of the constraint of Python 2.4, and hopefully 2.5. I know there are folk who are stuck with Python 2.5, but very few of these use SCons. As far as I am aware every operating system now treats 2.6 as the base, if it ships Python as standard.

I therefore propose that we raise the Python base to 2.6 (or even 2.7) and then begin a programme of making the codebase work on both 2 and 3.
Many project are going this route, even to the extent of using the 6 package to help maintain a single codebase.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder