<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 8:56 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've come to a cross roads for bitbake and python. Currently we run on<br>
python 2.7 but python 2.x is getting old and we really need to move to<br>
3.X.<br>
<br>
Whilst there are a number of tools out there which can translate<br>
between the two, we have the complexity that we have python both in<br>
bitbake itself and spread throughout the metadata. We could try and<br>
migrate, attempting to support both versions but it would require a lot<br>
of effort and I'm not sure we get much return for it. Its more likely<br>
we'd end up with a lot of subtle bugs.<br>
<br>
An alternative is we just have a flag day and switch, putting in<br>
patches to bitbake and the metadata to migrate to 3.X in one go. The<br>
advantage of this is much cleaner code without any workarounds for<br>
compatibility.<br>
<br>
I did some work on this a couple of years ago, I've dusted off those<br>
patches and improved upon them to get to the ones in:<br>
<br>
<a href="http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip" rel="noreferrer" target="_blank">http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip</a><br>
<br>
Right now, this is enough to be able to run "bitbake bash", there are a<br>
ton of things which still need to be done. The patches above are rather<br>
rough, the aim just being to find out if we can get the basics working<br>
which it appears we can.<br>
<br>
My proposal is we decide to have the flag day, we queue up the patches<br>
on a python3 branch both in oe-core and bitbake, then we switch when we<br>
get successful autobuilder builds. I'd ideally like to do this quite<br>
soon and get one with it (within a few weeks), leaving plenty of time<br>
to handle issues and the other changes planned for this release cycle<br>
and give other layers time to adapt.<br>
<br>
I will likely push things so the basics in the core work, I'll then<br>
need help for things like toaster, the QA framework, the supporting<br>
tools (devtool, recipetool and so on).<br>
<br>
Does anyone object to this?</blockquote><div><br></div><div>I fully support this effort, and the use of a flag day to switch and not maintain compatibility. We've wanted to move to 3 for a long time, after all.</div></div>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>