| Message ID | 20170220184134.25491-1-contact@paulk.fr |
|---|---|
| State | Accepted |
| Commit | 66a7a2464870700b17d7235ff247c45d705ed5f7 |
| Delegated to: | Tom Rini |
| Headers | show |
On 20 February 2017 at 11:41, Paul Kocialkowski <contact@paulk.fr> wrote: > We now live in a world where python cannot be assumed to be python2. > As a matter of fact, it is no longer the default for python on many > GNU/Linux distributions. > > Running binman with python3 fails, so explicitly request python2 from > env in the shebang for running it. > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr> > --- > tools/binman/binman.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass <sjg@chromium.org>
On Mon, Feb 20, 2017 at 07:41:34PM +0100, Paul Kocialkowski wrote: > We now live in a world where python cannot be assumed to be python2. > As a matter of fact, it is no longer the default for python on many > GNU/Linux distributions. > > Running binman with python3 fails, so explicitly request python2 from > env in the shebang for running it. On other systems such as OpenBSD the binary is python2.7 not python2 or python. Though there isn't really a way to handle this with how u-boot builds as I understand it (besides local patches). > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr> > --- > tools/binman/binman.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/binman/binman.py b/tools/binman/binman.py > index 4cc431fbbe..25a01d9adb 100755 > --- a/tools/binman/binman.py > +++ b/tools/binman/binman.py > @@ -1,4 +1,4 @@ > -#!/usr/bin/env python > +#!/usr/bin/env python2 > > # Copyright (c) 2016 Google, Inc > # Written by Simon Glass <sjg@chromium.org> > -- > 2.11.1 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
On Thu, Feb 23, 2017 at 12:25:48AM +1100, Jonathan Gray wrote: > On Mon, Feb 20, 2017 at 07:41:34PM +0100, Paul Kocialkowski wrote: > > We now live in a world where python cannot be assumed to be python2. > > As a matter of fact, it is no longer the default for python on many > > GNU/Linux distributions. > > > > Running binman with python3 fails, so explicitly request python2 from > > env in the shebang for running it. > > On other systems such as OpenBSD the binary is python2.7 not python2 > or python. Though there isn't really a way to handle this with > how u-boot builds as I understand it (besides local patches). I thought, but could be wrong, that "python2" was the canonical way name for the python 2.x binary.
On Wed, Feb 22, 2017 at 10:25:38AM -0500, Tom Rini wrote: > On Thu, Feb 23, 2017 at 12:25:48AM +1100, Jonathan Gray wrote: > > On Mon, Feb 20, 2017 at 07:41:34PM +0100, Paul Kocialkowski wrote: > > > We now live in a world where python cannot be assumed to be python2. > > > As a matter of fact, it is no longer the default for python on many > > > GNU/Linux distributions. > > > > > > Running binman with python3 fails, so explicitly request python2 from > > > env in the shebang for running it. > > > > On other systems such as OpenBSD the binary is python2.7 not python2 > > or python. Though there isn't really a way to handle this with > > how u-boot builds as I understand it (besides local patches). > > I thought, but could be wrong, that "python2" was the canonical way name > for the python 2.x binary. So, I looked harder at this and found https://www.python.org/dev/peps/pep-0394/ which in sum, to me says it is more reasonable to expect 'python2' to exist than it is to expect that 'python2.7' exists (but is also possibly getting out of date as it sounds like more than just Arch sets python to python3). That said, I also found issues that note that OSX (and as you note, OpenBSD) do not do python2 but rather python2.7 and that the "best" overall solution is to make the code compatible with python 2 and python 3 so that 'python' is still the correct thing to look for. My inclination for this release is to keep the current behavior and hope that for the next release someone has the time to make binman python2 and python3 compatible. We do this today with 'patman' but that tool is more optional than binman is and we certainly have the case today where patman will fail if the user doesn't have the "future" package installed in python. I almost wonder if making binman python3-only would be easier.
Hi, On 27 February 2017 at 09:26, Tom Rini <trini@konsulko.com> wrote: > On Wed, Feb 22, 2017 at 10:25:38AM -0500, Tom Rini wrote: >> On Thu, Feb 23, 2017 at 12:25:48AM +1100, Jonathan Gray wrote: >> > On Mon, Feb 20, 2017 at 07:41:34PM +0100, Paul Kocialkowski wrote: >> > > We now live in a world where python cannot be assumed to be python2. >> > > As a matter of fact, it is no longer the default for python on many >> > > GNU/Linux distributions. >> > > >> > > Running binman with python3 fails, so explicitly request python2 from >> > > env in the shebang for running it. >> > >> > On other systems such as OpenBSD the binary is python2.7 not python2 >> > or python. Though there isn't really a way to handle this with >> > how u-boot builds as I understand it (besides local patches). >> >> I thought, but could be wrong, that "python2" was the canonical way name >> for the python 2.x binary. > > So, I looked harder at this and found > https://www.python.org/dev/peps/pep-0394/ which in sum, to me says it is > more reasonable to expect 'python2' to exist than it is to expect that > 'python2.7' exists (but is also possibly getting out of date as it > sounds like more than just Arch sets python to python3). > > That said, I also found issues that note that OSX (and as you note, > OpenBSD) do not do python2 but rather python2.7 and that the "best" > overall solution is to make the code compatible with python 2 and > python 3 so that 'python' is still the correct thing to look for. > > My inclination for this release is to keep the current behavior and hope > that for the next release someone has the time to make binman python2 > and python3 compatible. We do this today with 'patman' but that tool is > more optional than binman is and we certainly have the case today where > patman will fail if the user doesn't have the "future" package installed > in python. I almost wonder if making binman python3-only would be > easier. I agree. I will make the time for this in a few weeks ,if someone doesn't kindly beat me to it. It should be possible to support both Python 2 and 3. Regarding the incompatibility of Python 2 and 3, I would like to add my approbation to the pile also. Regards, Simon
diff --git a/tools/binman/binman.py b/tools/binman/binman.py index 4cc431fbbe..25a01d9adb 100755 --- a/tools/binman/binman.py +++ b/tools/binman/binman.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python2 # Copyright (c) 2016 Google, Inc # Written by Simon Glass <sjg@chromium.org>
We now live in a world where python cannot be assumed to be python2. As a matter of fact, it is no longer the default for python on many GNU/Linux distributions. Running binman with python3 fails, so explicitly request python2 from env in the shebang for running it. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> --- tools/binman/binman.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)