GNU bug report logs - #74434
[PATCH] py-compile: Allow user to disable python

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74434 in the body.
You can then email your comments to 74434 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Frédéric Bérat <fberat <at> redhat.com>
To: automake-patches <at> gnu.org
Subject: [PATCH] py-compile: Allow user to disable python
Date: Tue, 19 Nov 2024 10:52:02 +0100

Hello,

While integrating automake 1.17, I found that otf2 package build fails.
The failure is due to:
	py-compile: could not determine : major version

This is a side-effect of a rework of the py-compile script, which
formerly defaulted to python3 if there was an error while getting the
python version.

The new code doesn't have this fallback, and if users want to disable
python support by setting `PYTHON=:` as environment variable, the script
bails out.

I believe this is a common practice and that py-compile needs a fix. I
therefore propose the one below.

Feel free to tell me otherwise.

Fred.

-- 8< --
Subject: [PATCH] py-compile: Allow user to disable python

Common practice is to set PYTHON=: to disable python support, which
breaks the current version of this script.

Check that the PYTHON variable contains `python`, early exit otherwise.
---
 lib/py-compile | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lib/py-compile b/lib/py-compile
index c9d4fde94..0238bab2c 100755
--- a/lib/py-compile
+++ b/lib/py-compile
@@ -33,6 +33,13 @@ fi
 
 me=py-compile
 
+case "$PYTHON" in
+  *python*) ;;
+  *)
+  echo "$me: Python support disabled";
+  exit 0;;
+esac
+
 usage_error ()
 {
   echo "$me: $*" >&2
-- 
2.47.0

Message #8 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fberat <at> redhat.com
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Tue, 19 Nov 2024 14:28:33 -0700

Hi Frederic,

    I believe this is a common practice 

Well, clearly no one had thought of it nor was it tried at any point
during the lengthy automake pretest sequence, but anyway, agreed that
there's no reason to gratuitously fail in this case.

As for disabling pythong, it doesn't seem to me that setting PYTHON=:
can really be considered equivalent to something like a --without-python
option, but since it helps in some cases, that's fine. --thanks, karl.

Message #11 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Frederic Berat <fberat <at> redhat.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Wed, 20 Nov 2024 15:02:19 +0100

[Message part 1 (text/plain, inline)]

On Tue, Nov 19, 2024 at 10:29 PM Karl Berry <karl <at> freefriends.org> wrote:

> Hi Frederic,
>
>     I believe this is a common practice
>
> Well, clearly no one had thought of it nor was it tried at any point
> during the lengthy automake pretest sequence, but anyway, agreed that
> there's no reason to gratuitously fail in this case.
>

> As for disabling pythong, it doesn't seem to me that setting PYTHON=:
> can really be considered equivalent to something like a --without-python
> option, but since it helps in some cases, that's fine. --thanks, karl.
>

Well, to rephrase: that is a construct I've already seen, not that I agree
or disagree with its usage in this usecase.

There may be a bit more thoughts needed to get the py-compile-env.sh test
to work properly though.

[Message part 2 (text/html, inline)]

Message #14 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fberat <at> redhat.com
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Wed, 20 Nov 2024 15:22:46 -0700

    There may be a bit more thoughts needed to get the py-compile-env.sh test
    to work properly though.

Yes, we should add an explicit check for this PYTHON=: setting.
If you have time to munge around in the test(s), that would be great.
Else I'll get to it when I get to it. --thanks, karl.
 

Message #17 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Frédéric Bérat <fberat <at> redhat.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Fri, 22 Nov 2024 13:27:10 +0100

Hi,

Here is a revision of the patch, so that py-compile-en.sh test passes.
I leave to you to decide if a test dedicated to "PYTHON=:" is truly necessary.

Fred.

-- 8< --
Subject: [PATCH v2] py-compile: Allow user to disable python

Common practice is to set PYTHON=: to disable python support, which
breaks the current version of this script.
---
 lib/py-compile      |  8 ++++++++
 t/py-compile-env.sh | 20 ++++++++++----------
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/lib/py-compile b/lib/py-compile
index c9d4fde94..332cb4b79 100755
--- a/lib/py-compile
+++ b/lib/py-compile
@@ -33,6 +33,14 @@ fi
 
 me=py-compile
 
+case "$PYTHON" in
+  *python*) ;;
+  *)
+  echo "$me: Invalid python executable ${PYTHON}";
+  echo "$me: Python support disabled";
+  exit 0;;
+esac
+
 usage_error ()
 {
   echo "$me: $*" >&2
diff --git a/t/py-compile-env.sh b/t/py-compile-env.sh
index b4ba6dcbe..7d8766b30 100644
--- a/t/py-compile-env.sh
+++ b/t/py-compile-env.sh
@@ -21,17 +21,17 @@
 cp "$am_scriptdir/py-compile" . \
   || fatal_ "failed to fetch auxiliary script py-compile"
 
-cat > my-py <<'END'
+cat > my-python <<'END'
 #!/bin/sh
 echo 2
-: > my-py.run
+: > my-python.run
 END
-chmod a+x my-py
+chmod a+x my-python
 
 mkdir sub1
 cd sub1
 
-PYTHON=false ../py-compile foo.py && exit 1
+! PYTHON=false ../py-compile foo.py && exit 1
 ls | grep . && exit 1
 
 PYTHON='echo GrEpMe AndMeToo' ../py-compile foo.py
@@ -42,16 +42,16 @@ cd ..
 mkdir sub2
 cd sub2
 
-PYTHON=../my-py ../py-compile foo.py
-test -f my-py.run
-ls | grep -v '^my-py\.run$' | grep . && exit 1
+PYTHON=../my-python ../py-compile foo.py
+test -f my-python.run
+ls | grep -v '^my-python\.run$' | grep . && exit 1
 
 cd ..
 mkdir sub3
 cd sub3
 PATH=..$PATH_SEPARATOR$PATH; export PATH
-PYTHON=my-py py-compile foo.py
-test -f my-py.run
-ls | grep -v '^my-py\.run$' | grep . && exit 1
+PYTHON=my-python py-compile foo.py
+test -f my-python.run
+ls | grep -v '^my-python\.run$' | grep . && exit 1
 
 :
-- 
2.47.0

Message #20 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fberat <at> redhat.com
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Sat, 23 Nov 2024 19:04:32 -0700

    +case "$PYTHON" in
    +  *python*) ;;
    +  *)
    +  echo "$me: Invalid python executable ${PYTHON}";
    +  echo "$me: Python support disabled";
    +  exit 0;;
    +esac

Thanks. But I'm not sure about requiring the executable name to include
"python". Apart from technically being against GNU standards, I can
imagine people making a link named anything and then using that. For
whatever reason.

Maybe it would suffice to run $PYTHON -V and see if the result matches
grep -i python?

I don't have Python 2.0 (the oldest we claim to support, though I have
my doubts), but it works with Python 2.7.

$ python2.7 -V
Python 2.7.18

Wdyt? --thanks, karl.

Message #23 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Frederic Berat <fberat <at> redhat.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Mon, 25 Nov 2024 08:14:41 +0100

[Message part 1 (text/plain, inline)]

On Sun, Nov 24, 2024 at 3:05 AM Karl Berry <karl <at> freefriends.org> wrote:

>     +case "$PYTHON" in
>     +  *python*) ;;
>     +  *)
>     +  echo "$me: Invalid python executable ${PYTHON}";
>     +  echo "$me: Python support disabled";
>     +  exit 0;;
>     +esac
>
> Thanks. But I'm not sure about requiring the executable name to include
> "python". Apart from technically being against GNU standards, I can
> imagine people making a link named anything and then using that. For
> whatever reason.
>
> Maybe it would suffice to run $PYTHON -V and see if the result matches
> grep -i python?
>
> I don't have Python 2.0 (the oldest we claim to support, though I have
> my doubts), but it works with Python 2.7.
>
> $ python2.7 -V
> Python 2.7.18
>
> Wdyt? --thanks, karl.
>

That sounds reasonable.

[Message part 2 (text/html, inline)]

Message #26 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fberat <at> redhat.com
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Mon, 3 Feb 2025 11:07:54 -0700

    Here is a revision of the patch, so that py-compile-en.sh test passes.

Here's another attempt at the patch, calling $PYTHON -V instead of using
the name of $0 to decide if it's really Python. Wdyt?

The result is that $PYTHON can be set to anything at all and py-compile
will succeed. Since the goal is to support "disabling" via PYTHON=:.

I can't see how to reasonably support the previous behavior of PYTHON=:
succeeding and PYTHON=false failing, unless we make a special case for :
(and true and ...?), which seems undesirable. Do you (or anyone) think
we need to worry about this, or is it ok for py-compile to now succeed
with any value of $PYTHON? I worry people assumed the previous bizarre
behavior in their Makefiles.

Thanks,
Karl

diff --git a/lib/py-compile b/lib/py-compile
index 9659beca6..d68a4431e 100755
--- a/lib/py-compile
+++ b/lib/py-compile
@@ -33,6 +33,15 @@ fi
 
 me=py-compile
 
+# People apparently set PYTHON=: and expect the result to be true.
+# This means setting PYTHON=false will also exit true, but what can we do?
+# For the same reason, we output to stdout instead of stderr. Bizarre.
+if $PYTHON -V 2>/dev/null | grep -i python; then :; else
+  echo "$me: Invalid python executable (according to -V): $PYTHON"
+  echo "$me: Python support disabled"
+  exit 0
+fi
+  
 usage_error ()
 {
   echo "$me: $*" >&2
diff --git a/t/py-compile-env.sh b/t/py-compile-env.sh
index 564fb98c6..fc82df43a 100644
--- a/t/py-compile-env.sh
+++ b/t/py-compile-env.sh
@@ -31,7 +31,13 @@ chmod a+x my-py
 mkdir sub1
 cd sub1
 
-PYTHON=false ../py-compile foo.py && exit 1
+# This should succeed and do nothing.
+PYTHON=: ../py-compile foo.py
+ls | grep . && exit 1
+
+# This command will also succeed, since we intentionally allow PYTHON to
+# be set to anything.
+PYTHON=false ../py-compile foo.py
 ls | grep . && exit 1
 
 PYTHON='echo GrEpMe AndMeToo' ../py-compile foo.py

compile finished at Mon Feb  3 10:04:09 2025

Message #29 received at 74434 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fberat <at> redhat.com
Cc: 74434 <at> debbugs.gnu.org
Subject: Re: [bug#74434] [PATCH] py-compile: Allow user to disable python
Date: Sun, 9 Feb 2025 10:36:47 -0700

Hi Frederic and all - I installed the following patch to py-compile.
Hopefully it restores the previous behavior of setting the PYTHON envvar
to whatever and "disabling" the compilation (but exiting succesfully).

Hope it flies, let me know if problems. --thanks, karl.

-----------------------------------------------------------------------------
python: restore more compatible behavior for $PYTHON.	

For https://bugs.gnu.org/74434.

* lib/py-compile: if $PYTHON -V does not include the 
string "python" (case-insensitive), consider the support
intentionally disabled and exit successfully, unless PYTHON is set
to false, in which case exit unsuccessfully. This is closer to
the old behavior. Mention this in the help message.
* t/py-compile-env.sh: add test for PYTHON=:.
* NEWS: mention this. (And, en passant, add some past bug#s and
clarify that only RCS/SCCS pattern rules were disabled, not all.)
diff --git a/NEWS b/NEWS
index f667c8727..22bd6a585 100644
--- a/NEWS
+++ b/NEWS
@@ -6,7 +6,7 @@ New in 1.x:

 * New supported languages

-  - Support for Algol 68 added, based on the GNU Algol 68 compiler.
+  - Support for Algol 68 added, based on the GNU Algol 68 compiler. (bug#75807)

 * Miscellaneous changes

@@ -19,7 +19,14 @@ New in 1.x:

   - Avoid Perl 5.41.8+ precedence warning for use of !!.

-  - The compile script is more robust to various Windows configurations.
+  - The py-compile script once again does nothing (successfully) if the
+    PYTHON environment variable is set to ":", or anything that isn't a
+    Python interpreter (according to $PYTHON -V). Exception: if PYTHON
+    is set to "false", do nothing but exit unsuccessfully, also to match
+    previous behavior. (bug#74434)
+
+  - The compile script is more robust to Windows configurations;
+    specifically, avoiding double-path translation on MSYS. (bug#75939)

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@@ -51,8 +58,8 @@ New in 1.17:
     retained when appended.  GNU Make & BSD Makes are known to support it.
     (bug#7610)

-  - GNU Make's default pattern rules are disabled, for speed and debugging.
-    (.SUFFIXES was already cleared.) (bug#64743)
+  - GNU Make's default pattern rules for RCS and SCCS are disabled, for
+    speed and debugging. (.SUFFIXES was already cleared.) (bug#64743)

   - For Texinfo documents, if a .texi.in file exists, but no .texi, the
     .texi.in will be read. Texinfo source files need not be present at
diff --git a/lib/py-compile b/lib/py-compile
index 9659beca6..0cfddedb6 100755
--- a/lib/py-compile
+++ b/lib/py-compile
@@ -33,6 +33,23 @@ fi

 me=py-compile

+# People apparently set PYTHON=: and expect the result to be true.
+# For the same reason, we output to stdout instead of stderr. Bizarre.
+if $PYTHON -V 2>/dev/null | grep -i python >/dev/null; then :; else
+  echo "$me: Invalid python executable (according to -V): $PYTHON"
+  echo "$me: Python support disabled"
+  if test x"$PYTHON" = xfalse; then
+    # But, as a special case, make PYTHON=false exit unsuccessfully,
+    # since that was the traditional behavior.
+    exit 1
+    # In the past, setting PYTHON to any command that exited unsuccessfully
+    # caused py-compile to exit unsuccessfully. Let's not try to
+    # replicate that unless and until needed.
+  else
+   exit 0
+  fi
+fi
+  
 usage_error ()
 {
   echo "$me: $*" >&2
@@ -64,7 +81,7 @@ while test $# -ne 0; do
       cat <<\EOF
 Usage: py-compile [options] FILES...

-Byte compile some python scripts FILES.  Use --destdir to specify any
+Byte compile FILES as Python scripts.  Use --destdir to specify a
 leading directory path to the FILES that you don't want to include in the
 byte compiled file.  Specify --basedir for any additional path information you
 do want to be shown in the byte compiled file.
@@ -78,6 +95,14 @@ Options:
 Example:
   py-compile --destdir /tmp/pkg-root --basedir /usr/share/test test.py test2.py

+The Python interpreter to use is taken from the environment variable
+PYTHON, or "python" by default.
+
+For compatibility: as a special case, if PYTHON=false (that is, the
+command named "false"), this script will exit unsuccessfully. Otherwise,
+if $PYTHON -V does not include the string "Python", this script will
+emit a message to standard output and exit successfully.
+
 Report bugs to <bug-automake <at> gnu.org>.
 GNU Automake home page: <https://www.gnu.org/software/automake/>.
 General help using GNU software: <https://www.gnu.org/gethelp/>.
diff --git a/t/py-compile-env.sh b/t/py-compile-env.sh
index 564fb98c6..3411ddd5d 100644
--- a/t/py-compile-env.sh
+++ b/t/py-compile-env.sh
@@ -31,9 +31,15 @@ chmod a+x my-py
 mkdir sub1
 cd sub1

+# This py-compile invocation should succeed and do nothing.
+PYTHON=: ../py-compile foo.py
+ls | grep . && exit 1
+
+# This py-compile invocation should fail and do nothing.
 PYTHON=false ../py-compile foo.py && exit 1
 ls | grep . && exit 1

+# These should also do nothing, and succeed.
 PYTHON='echo GrEpMe AndMeToo' ../py-compile foo.py
 PYTHON='echo GrEpMe AndMeToo' ../py-compile foo.py | grep 'GrEpMe AndMeToo'
 ls | grep . && exit 1

compile finished at Sun Feb  9 09:36:24 2025

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.