Re: [openstack-dev] [TripleO][DIB] diskimage-builder and python 2/3 compatibility
On 12/09/2015 07:15 AM, Gregory Haynes wrote: > We ran in to a couple issues adding Fedora 23 support to > diskimage-builder caused by python2 not being installed by default. > This can be solved pretty easily by installing python2, but given that > this is eventually where all our supported distros will end up I would > like to find a better long term solution (one that allows us to make > images which have the same python installed that the distro ships by > default). So I wonder if we're maybe hitting premature optimisation with this > We use +x and a #! to specify a python > interpreter, but this needs to be python3 on distros which do not ship a > python2, and python elsewhere. > Create a symlink in the chroot from /usr/local/bin/dib-python to > whatever the apropriate python executable is for that distro. This is a problem for anyone wanting to ship a script that "just works" across platforms. I found a similar discussion about a python launcher at [1] which covers most points and is more or less what is described above. I feel like contribution to some sort of global effort in this regard might be the best way forward, and then ensure dib uses it. -i [1] https://mail.python.org/pipermail/linux-sig/2015-October/00.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][DIB] diskimage-builder and python 2/3 compatibility
Excerpts from Ian Wienand's message of 2015-12-09 09:35:15 +: > On 12/09/2015 07:15 AM, Gregory Haynes wrote: > > We ran in to a couple issues adding Fedora 23 support to > > diskimage-builder caused by python2 not being installed by default. > > This can be solved pretty easily by installing python2, but given that > > this is eventually where all our supported distros will end up I would > > like to find a better long term solution (one that allows us to make > > images which have the same python installed that the distro ships by > > default). > > So I wonder if we're maybe hitting premature optimisation with this That's a fair point. My thinking is that this is a thing we are hitting now, and if we do not fix this then we are going to end up adding a python2 dependency everywhere. This isn't the worst thing, but if we end up wanting to remove that later it will be a backwards incompat issue. So IMO if it's easy enough to get correct now it would be awesome to do rather than ripping python2 out from underneath users at a later date. > > > We use +x and a #! to specify a python > > interpreter, but this needs to be python3 on distros which do not ship a > > python2, and python elsewhere. > > > Create a symlink in the chroot from /usr/local/bin/dib-python to > > whatever the apropriate python executable is for that distro. > > This is a problem for anyone wanting to ship a script that "just > works" across platforms. I found a similar discussion about a python > launcher at [1] which covers most points and is more or less what > is described above. > > I feel like contribution to some sort of global effort in this regard > might be the best way forward, and then ensure dib uses it. > > -i > > [1] https://mail.python.org/pipermail/linux-sig/2015-October/00.html > My experience has been that this is something the python community doesn't necessarially want (it would be pretty trivial to fix with a python2or3 runner). I half expected some feedback of "please don't do that, treat python2 and 3 as separate languages", which was a big reason for this post. This is even more complicated by it being a distro-specific issue (some distros do ship a /usr/bin/python which points to either 2 or 3, depending on what is available). Basically, yes, it would be great for the larger python community to solve this but I am not hopeful of that actually happening. We do need to come up with some kind of fix in the meantime. As I mentioned above, the 'just install python2' fix has some annoyances later down the road, and my thinking is that the symlink approach is not much more work without the same problems for us... Cheers, Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][DIB] diskimage-builder and python 2/3 compatibility
Excerpts from Gregory Haynes's message of 2015-12-09 12:49:07 -0800: > Excerpts from Ian Wienand's message of 2015-12-09 09:35:15 +: > > On 12/09/2015 07:15 AM, Gregory Haynes wrote: > > > We ran in to a couple issues adding Fedora 23 support to > > > diskimage-builder caused by python2 not being installed by default. > > > This can be solved pretty easily by installing python2, but given that > > > this is eventually where all our supported distros will end up I would > > > like to find a better long term solution (one that allows us to make > > > images which have the same python installed that the distro ships by > > > default). > > > > So I wonder if we're maybe hitting premature optimisation with this > > That's a fair point. My thinking is that this is a thing we are hitting > now, and if we do not fix this then we are going to end up adding a > python2 dependency everywhere. This isn't the worst thing, but if we end > up wanting to remove that later it will be a backwards incompat issue. > So IMO if it's easy enough to get correct now it would be awesome to do > rather than ripping python2 out from underneath users at a later date. > +1 to spending a few brain cycles trying to decide if we can avoid churn for users later. What we do in the guest should be carefully considered. > > > > > We use +x and a #! to specify a python > > > interpreter, but this needs to be python3 on distros which do not ship a > > > python2, and python elsewhere. > > > > > Create a symlink in the chroot from /usr/local/bin/dib-python to > > > whatever the apropriate python executable is for that distro. > > > > This is a problem for anyone wanting to ship a script that "just > > works" across platforms. I found a similar discussion about a python > > launcher at [1] which covers most points and is more or less what > > is described above. > > > > I feel like contribution to some sort of global effort in this regard > > might be the best way forward, and then ensure dib uses it. > > > > -i > > > > [1] https://mail.python.org/pipermail/linux-sig/2015-October/00.html > > > > My experience has been that this is something the python community > doesn't necessarially want (it would be pretty trivial to fix with a > python2or3 runner). I half expected some feedback of "please don't do > that, treat python2 and 3 as separate languages", which was a big reason > for this post. This is even more complicated by it being a > distro-specific issue (some distros do ship a /usr/bin/python which > points to either 2 or 3, depending on what is available). Basically, > yes, it would be great for the larger python community to solve this but > I am not hopeful of that actually happening. > Really there are 3 languages: python2 only python3 only python2or3 And when you've been good and used python2or3 ... it would be nice to be able to just express that without the machinery of setuptools and entry points (which is the other option here btw) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][DIB] diskimage-builder and python 2/3 compatibility
Hello everyone, I am hoping for some feedback from our developers/users on a potential solution to a python 2/3 compatibility issue we are hitting in dib: We ran in to a couple issues adding Fedora 23 support to diskimage-builder caused by python2 not being installed by default. This can be solved pretty easily by installing python2, but given that this is eventually where all our supported distros will end up I would like to find a better long term solution (one that allows us to make images which have the same python installed that the distro ships by default). The problem is that many elements provide python scripts (such as package-installs-v2 in the package-installs element) which we exec during the image build process. We use +x and a #! to specify a python interpreter, but this needs to be python3 on distros which do not ship a python2, and python elsewhere. There is also one script (pacakge-installs-squash) which runs outside of the chroot, but otherwise all python scripts run inside the chroot. Some brainstorming was done in #tripleo, and we came up with the following plan for fixing this: Create a symlink in the chroot from /usr/local/bin/dib-python to whatever the apropriate python executable is for that distro. We will then use dib-python in our #! lines for scripts which run in the chroot. Scripts outside of the chroot will have to perform their own python version detection and call any python using the detected python interpreter - this is only one package-installs-squash script so this seemed like not a big issue. The other solutions we considered: Switching everything to depend on python3 - This is ruled out since rhel7/centos7 do not ship a python3 package. Automatically rewriting #! lines as we exec them - This could work. I personally think the sylink is simpler and solves the problem equally as well. Thoughts? Cheers, Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
