[Scons-dev] no more print statements in SConscripts?

Wed May 25 19:13:15 EDT 2016

Well,

It's not specific to this print issue.
This is something which already came up when discussing installation through pip and the idea to stop supporting installing multiple scons versions on the same machine.
It also almost happened with Dirk changes some times ago (removing path, abspath, ...), but we came up with a fix to keep compatible.

It's about how to deal with a scons change breaking a user build system:

Consider a user who has one single scons installed on his server, and who wants to use the new scons version requiring updating SConstruct or SConscripts.
As he will be updating the single scons installed on his server, he'll be forced to update his SConstruct and SConscripts, not only in his current dev branch, but also in all his active maintenance branches. And even after this update work, some use cases will remain broken: any time he'll need to checkout and rebuild an old tag, this will fail as well, he'll have to fix his SConsctruct again. And if this checkout+build is handled automatically from a Jenkins, it won't even be possible at all.

On a user perspective, I think this is not acceptable. His only alternative would be to stick with his current scons and never update it again.

So, my point is, if the port to python3 requires the use of print(), which I can totally understand, the user should have the possibility to use different scons versions according to his product versions, whatever the solution is:
    - multiple versions installed side by side, selected for example by a different PATH
    - virtualenv, as Bill wrote.
    - build bootstrap which downloads a portable scons install
    - ....

But a solution must be given and documented if a scons release requires a change in users build systems, to keep supporting all old versions of theirs products. I obviously speak about my situation here, but I can't imagine I'm the only one to have to support years of old versions of my products. And my feeling is that without a clear solution to this issue, I can't afford upgrading.

Obviously, not introducing any "api break" would be the best, but I don't see where Tim suggests a solution. Tim wrote about "removing print statements from his SConscripts", which is exactly the painful case I described.

--
Alexandre Feblot

> Le 26 mai 2016 à 00:32, Bill Deegan <bill at baddogconsulting.com> a écrit :
> 
> Alexandre,
> 
> the code in Default is not currently released.
> So if you're running against the development code it's always "Buyer beware".
> 
> It seems likely we will be able to resolve the print_function issue as Tim has suggested.
> 
> Additionally, I don't see the need to install multiple versions of a tool on a system as onerous.
> Especially one which can be installed via virtualenv. (once it completely is)
> 
> -Bill
> 
> On Wed, May 25, 2016 at 2:57 PM, Alexandre Feblot <alexandre at feblot.fr <mailto:alexandre at feblot.fr>> wrote:
> So, here we are, we get an incompatibility with existing product build systems based on current scons, and thus, the need to support multiple versions of scons installed on the same machine, so we can keep compiling all old maintenance branches and all old tags of our products without having to fix all of them?
> 
>  
> --
> Alexandre Feblot
> 
>> Le 25 mai 2016 à 23:47, Tim Jenness <tjenness at lsst.org <mailto:tjenness at lsst.org>> a écrit :
>> 
>>> 
>>> On May 25, 2016, at 14:38, Bill Deegan <bill at baddogconsulting.com <mailto:bill at baddogconsulting.com>> wrote:
>>> 
>>> Tim,
>>> 
>>> Here's the implementation:
>>> https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251 <https://bitbucket.org/scons/scons/src/1e0827962a2bb114041df47d44be2384c86f3918/src/engine/SCons/Script/SConscript.py?at=default&fileviewer=file-view-default#SConscript.py-251>
>>> 
>>> Basically it exec()'s the SConscript as follows:
>>>  <>                            exec(compile(_file_.read(), _file_.name, 'exec'),
>>>  <>                                 call_stack[-1].globals)
>>> 
>>> So given that print_function() is already imported from __future__ at that point I don't think we can do a per SConscript exclusion?
>>> 
>> 
>> Right. It compiles a string so print_function is in effect.
>> 
>> I think what I’d do is ban the use of print in that file so that the print_function directive is not active. There are only two prints in there so I’d move those two routines to a different file or provide a utility print routine from somewhere else that those functions use.
>> 
>> — 
>> Tim Jenness
>> 
>> 
>> 
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org <mailto:Scons-dev at scons.org>
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
> 
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org <mailto:Scons-dev at scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
> 
> 
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160526/982b52b7/attachment-0001.html>