Re: [Scons-dev] SCons and Python 3.0
On Sat, Mar 7, 2015 at 5:58 AM, Bill Deegan b...@baddogconsulting.com wrote: Anatoly, How long do the builds of wesnoth and blender take? (on a reasonable, but not super fast/new machine) Wesnoth - about 30 minutes - https://travis-ci.org/wesnoth/wesnoth/builds/54652949 Blender - aboot 12 minutes ? - https://builder.blender.org/builders/mac_i386_10_6_scons/builds/843 ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
I emailed drone.io and they said for open source projects the would increase the runtime limts. I just need to create a official SCons account there and get things going On Saturday, March 7, 2015, Andrew Featherstone andrew.featherst...@cantab.net wrote: On 07/03/15 08:29, Russel Winder wrote: On Fri, 2015-03-06 at 21:58 -0500, Bill Deegan wrote: Anatoly, How long do the builds of wesnoth and blender take? (on a reasonable, but not super fast/new machine) I may have missed something in the past, but is there a reason we are not making use of Travis-CI, Snap-CI, Codeship, Drone.io as well as running the core Buildbot? I have to admit I have tried for a Python codebase, but for my Groovy codebases, these public CIs are well worth it. Not just for the CI, but also for the marketing angle of the fact that the projects are publicly visible. So I suggest we get SCons up there even if it is just for show. We may then find we can use the systems to handle these out of band builds. I tried using Drone.io with my own development branch on Bitbucket, but there is a 15 minute time limit on builds (see the Limits section here http://docs.drone.io/buildscript.html) so the regression suite doesn't complete. If anyone's interested my builds are at https://drone.io/bitbucket.org/ajf58/scons. Travis is tightly coupled to using Github and they seem very against adding support for projects on Bitbucket (see https://github.com/travis-ci/travis-ci/issues/667) and it looks like Snap-CI is similarly tied to the de-facto home of OSS. I'm as keen as I was back in July 2014 (https://pairlist2.pair.net/ pipermail/scons-dev/2014-July/001511.html) to see something happen to the issues on Tigris. The priority assignments just don't seem to translate to what's fixed in subsequent point releases, which makes it a really confusing list to browse. Andrew ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Fri, 2015-03-06 at 21:58 -0500, Bill Deegan wrote: Anatoly, How long do the builds of wesnoth and blender take? (on a reasonable, but not super fast/new machine) I may have missed something in the past, but is there a reason we are not making use of Travis-CI, Snap-CI, Codeship, Drone.io as well as running the core Buildbot? I have to admit I have tried for a Python codebase, but for my Groovy codebases, these public CIs are well worth it. Not just for the CI, but also for the marketing angle of the fact that the projects are publicly visible. So I suggest we get SCons up there even if it is just for show. We may then find we can use the systems to handle these out of band builds. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On 07/03/15 08:29, Russel Winder wrote: On Fri, 2015-03-06 at 21:58 -0500, Bill Deegan wrote: Anatoly, How long do the builds of wesnoth and blender take? (on a reasonable, but not super fast/new machine) I may have missed something in the past, but is there a reason we are not making use of Travis-CI, Snap-CI, Codeship, Drone.io as well as running the core Buildbot? I have to admit I have tried for a Python codebase, but for my Groovy codebases, these public CIs are well worth it. Not just for the CI, but also for the marketing angle of the fact that the projects are publicly visible. So I suggest we get SCons up there even if it is just for show. We may then find we can use the systems to handle these out of band builds. I tried using Drone.io with my own development branch on Bitbucket, but there is a 15 minute time limit on builds (see the Limits section here http://docs.drone.io/buildscript.html) so the regression suite doesn't complete. If anyone's interested my builds are at https://drone.io/bitbucket.org/ajf58/scons. Travis is tightly coupled to using Github and they seem very against adding support for projects on Bitbucket (see https://github.com/travis-ci/travis-ci/issues/667) and it looks like Snap-CI is similarly tied to the de-facto home of OSS. I'm as keen as I was back in July 2014 (https://pairlist2.pair.net/pipermail/scons-dev/2014-July/001511.html) to see something happen to the issues on Tigris. The priority assignments just don't seem to translate to what's fixed in subsequent point releases, which makes it a really confusing list to browse. Andrew ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Wed, Feb 25, 2015 at 10:29 PM, Bill Deegan b...@baddogconsulting.com wrote: Greetings! I believe the goal should be that a single codebase would work on python 2.7 and 3.x Given that premise I think having a separate branch for 3.0 work would just end up in much additional work. I'd like to add some python 3.0 buildslaves and then add small changes to trunk which would work towards the goal of the code working on py 2.7 and 3.x. Otherwise we'll have to maintain a longstanding branch for 3.0 work. Since it's unlikely that such changes will be huge architectural changes, but mainly should be minor code changes this should be a relatively safe path.. Thoughts? You need to setup buildbots for all bug projects like Wesnoth and Blender etc. that use SCons. Then the harness will be fair. Otherwise there inevitably will be compatibility breaks. It is very easy to break things when going this way. 2/3 codebase is significantly harder to maintain. You insert something for Python 2 and it breaks Python 3 and vice versa. Some bugs are not evident at all, because the type of returned object changes and it may not support some methods that will be called down the chain. So my bet is that without the harness 80% chance that new scon5 will give headache to all its former users ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Thu, 2015-02-26 at 09:51 -0800, Bill Deegan wrote: Russel, Do they have a rhel7 clone yet? It may be there is Scientific Linux and the Scientific Linux some organizations are stuck with. I have no idea why they use Scientific Linux, it may be that it is stable, i.e. it hasn't changed in eons. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
Russel, Do they have a rhel7 clone yet? -Bill On Thu, Feb 26, 2015 at 3:42 AM, Russel Winder rus...@winder.org.uk wrote: On Wed, 2015-02-25 at 15:03 -0800, Bill Deegan wrote: Russel, Minor nit. RHEL7/Centos7 has python 2.7.5 so they haven't fixed themselves at 2.6 Sadly Scientific Linux is still stuck on Python 2.6 :-((( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Wed, 2015-02-25 at 15:03 -0800, Bill Deegan wrote: Russel, Minor nit. RHEL7/Centos7 has python 2.7.5 so they haven't fixed themselves at 2.6 Sadly Scientific Linux is still stuck on Python 2.6 :-((( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
Bill, On 25.02.2015 20:29, Bill Deegan wrote: Greetings! I believe the goal should be that a single codebase would work on python 2.7 and 3.x Given that premise I think having a separate branch for 3.0 work would just end up in much additional work. you're aware of the fact that we already have a branch for this (python3-port)? I'd like to add some python 3.0 buildslaves and then add small changes to trunk which would work towards the goal of the code working on py 2.7 and 3.x. Otherwise we'll have to maintain a longstanding branch for 3.0 work. Since it's unlikely that such changes will be huge architectural changes, but mainly should be minor code changes this should be a relatively safe path.. Thoughts? At some point after the v2.5 release, we should probably just merge the current python3-port into default...and then put all our efforts into making it work. From then on it's a mixed 2.7/3.x codebase...and we don't look back. Just my 2 cents, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Wed, 2015-02-25 at 21:10 +0100, Dirk Bächle wrote: […] you're aware of the fact that we already have a branch for this (python3-port)? It is though now seriously out of date, and not being worked on by people doing things, just talked about by people like me hoping things. […] At some point after the v2.5 release, we should probably just merge the current python3-port into default...and then put all our efforts into making it work. From then on it's a mixed 2.7/3.x codebase...and we don't look back. I am for this idea. Keep a set of Python 2.7 buildbots which must always be green and a set of Python 3.4 buildbots on the same codebase which we try and get green a quickly as possible. I think the experiment with two long-lived branches has proven ineffective. I am very much for a single code base that always work on 2.7 and moves to be working on 3.4. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Wed, Feb 25, 2015 at 3:31 PM, Russel Winder rus...@winder.org.uk wrote: On Wed, 2015-02-25 at 21:10 +0100, Dirk Bächle wrote: […] you're aware of the fact that we already have a branch for this (python3-port)? It is though now seriously out of date, and not being worked on by people doing things, just talked about by people like me hoping things. It shouldn't be all that out of date. I merged default branch into it last year; there haven't been huge changes since then. Doing another merge into it to keep it current should not be a big task. The idea is that at some point (not all that far from now) it should get finished (so the tests pass) and merged back into the default branch, then we have a working 2.7/3.x codebase. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On Wed, 2015-02-25 at 21:28 +0100, i...@fibrecode.com wrote: Question, what's going on on python3-port at all. Is it still active? On https://bitbucket.org/scons/scons/branch/python3-port last entry is April 2014. No and yes. I like scons and I like python3. I'm not sure, if people really need both versions forever. Sadly Guido extended Python 2.7 EOL from 2017 to 2020, which is an admission it will never actually go away :-( On a more serious note, there are some applications, such as Mercurial, which have indicated they may never to move to Python 3 as they cannot deal with the change from ASCII to Unicode for strings. I installed python2.7 just for scons, and many people are moving forward to use python3 only. Some people do not have that luxury. Although Canonical have taken Ubuntu to Python 3, Red Hat are still shipping Python 2.6 as their up-to-date version of Python. I am a Python 3 only person and only have Python 2 for Mercurial and SCons. If I had my way Python 2 would be eradicated two years ago! Why not put python2.7 in stable branch for maintenance only, and just work on python3 in trunk. Pragmatically, the right place to be is Python 2.7 and Python 3.4 compliance in a single code base. This is fairly straightforward compared to all other solutions, provided we can get the person power harnessed – not entirely straightforward in a project with only volunteer labour. It's a pity having said Python 2.7 is the floor version, we keep supporting 2.6. I understand why sort of, but it doesn't stop me complaining :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
On 25.02.2015 22:55, Russel Winder wrote: On Wed, 2015-02-25 at 21:28 +0100, i...@fibrecode.com wrote: Question, [...] Why not put python2.7 in stable branch for maintenance only, and just work on python3 in trunk. Pragmatically, the right place to be is Python 2.7 and Python 3.4 compliance in a single code base. This is fairly straightforward compared to all other solutions, provided we can get the person power harnessed – not entirely straightforward in a project with only volunteer labour. +1, and I think the big part of the work is already done. We just need to focus our efforts on the remaining 5% (which admittedly might have a lot of hard nuts in them) for some time...and can make it happen. Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
Russel, Minor nit. RHEL7/Centos7 has python 2.7.5 so they haven't fixed themselves at 2.6 -Bill On Wed, Feb 25, 2015 at 1:55 PM, Russel Winder rus...@winder.org.uk wrote: On Wed, 2015-02-25 at 21:28 +0100, i...@fibrecode.com wrote: Question, what's going on on python3-port at all. Is it still active? On https://bitbucket.org/scons/scons/branch/python3-port last entry is April 2014. No and yes. I like scons and I like python3. I'm not sure, if people really need both versions forever. Sadly Guido extended Python 2.7 EOL from 2017 to 2020, which is an admission it will never actually go away :-( On a more serious note, there are some applications, such as Mercurial, which have indicated they may never to move to Python 3 as they cannot deal with the change from ASCII to Unicode for strings. I installed python2.7 just for scons, and many people are moving forward to use python3 only. Some people do not have that luxury. Although Canonical have taken Ubuntu to Python 3, Red Hat are still shipping Python 2.6 as their up-to-date version of Python. I am a Python 3 only person and only have Python 2 for Mercurial and SCons. If I had my way Python 2 would be eradicated two years ago! Why not put python2.7 in stable branch for maintenance only, and just work on python3 in trunk. Pragmatically, the right place to be is Python 2.7 and Python 3.4 compliance in a single code base. This is fairly straightforward compared to all other solutions, provided we can get the person power harnessed – not entirely straightforward in a project with only volunteer labour. It's a pity having said Python 2.7 is the floor version, we keep supporting 2.6. I understand why sort of, but it doesn't stop me complaining :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
Dirk, On Wed, Feb 25, 2015 at 12:10 PM, Dirk Bächle tshor...@gmx.de wrote: Bill, On 25.02.2015 20:29, Bill Deegan wrote: Greetings! I believe the goal should be that a single codebase would work on python 2.7 and 3.x Given that premise I think having a separate branch for 3.0 work would just end up in much additional work. you're aware of the fact that we already have a branch for this (python3-port)? Uhm.. oops. slipped my mind. I'd like to add some python 3.0 buildslaves and then add small changes to trunk which would work towards the goal of the code working on py 2.7 and 3.x. Otherwise we'll have to maintain a longstanding branch for 3.0 work. Since it's unlikely that such changes will be huge architectural changes, but mainly should be minor code changes this should be a relatively safe path.. Thoughts? At some point after the v2.5 release, we should probably just merge the current python3-port into default...and then put all our efforts into making it work. From then on it's a mixed 2.7/3.x codebase...and we don't look back. Yes. I think this is the best course of action. -Bill ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Python 3.0
As a side note, I think it is important that end-users understand that we will always require the latest release of 2.7 so that we can fully leverage 3.X back-ported tools. V/R, William On Wed, Feb 25, 2015 at 8:35 PM, William Blevins wblevins...@gmail.com wrote: On Wed, Feb 25, 2015 at 5:12 PM, Dirk Bächle tshor...@gmx.de wrote: On 25.02.2015 22:55, Russel Winder wrote: On Wed, 2015-02-25 at 21:28 +0100, i...@fibrecode.com wrote: Question, [...] Why not put python2.7 in stable branch for maintenance only, and just work on python3 in trunk. Pragmatically, the right place to be is Python 2.7 and Python 3.4 compliance in a single code base. This is fairly straightforward compared to all other solutions, provided we can get the person power harnessed – not entirely straightforward in a project with only volunteer labour. +1, and I think the big part of the work is already done. We just need to focus our efforts on the remaining 5% (which admittedly might have a lot of hard nuts in them) for some time...and can make it happen. Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev +1, I agree with trying to support 2.7 and 3.X within a single code base. We may reach a case were this become impractical, but I think we should at least make an initial effort to understand this cases if they exist. I am on board with the proposal for working this issue out of trunk once 2.5 is released. Making updates can follow the same path for standard release fixes and 3.X port work; thus, facilitating the mentality to keep new changes 3.X compliant, and possibly reducing the total workload. V/R, William ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
