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 <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>>
>>> On May 25, 2016, at 14:38, Bill Deegan <[email protected]
>>> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
>
> _______________________________________________
> Scons-dev mailing list
> [email protected] <mailto:[email protected]>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> <https://pairlist2.pair.net/mailman/listinfo/scons-dev>
>
>
> _______________________________________________
> Scons-dev mailing list
> [email protected]
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
