Add explicit test for Python >= v3.7 in configure

[jsquyres]

Open MPI's Python scripts have been tested with v3.6 and work, but the pympistandard module requires Python >= v3.7. Hence, the minimum Python version required is v3.7.

• Add an explicit test to early in configure.ac for Python >= v3.7 if:
  • We're building the Fortran MPI bindings
  • We're in a Git clone
• Remove a test later in configure for Python >= v3.6 for generating the Fortran bindings
• Update several places in the docs to note that Open MPI now requires Python >= v3.7 to build in certain conditions
• Maintain the minimum required Python version in VERSION (along with other external dependency minimum versions)

Fixes #13242

[jsquyres]

This PR failed CI because one of our CI agents builds on EOL Ubuntu 18, which has Python 3.6 -- hence, it (correctly) fails the configure test looking for Python 3.7.

[rhc54]

Just curious - have we confirmed that Python 3.7 is sufficient for the show-help conversion scripts? I know I had to make some changes when shifting down from 3.12 to run on our CI. Not sure how low those go.

[jsquyres]

Just curious - have we confirmed that Python 3.7 is sufficient for the show-help conversion scripts? I know I had to make some changes when shifting down from 3.12 to run on our CI. Not sure how low those go.

Yes. I can even run it with Python 3.6 (just tried it again, just to be sure).

I asked AI what distros ship with Python 3.6; here's what it said:

• Ubuntu 18.04 LTS (Bionic Beaver) comes with Python 3.6.
• Ubuntu 16.04 LTS (Xenial Xerus) includes Python 3.5.
• Debian 9 (Stretch) includes Python 3.5.
• Debian 8 (Jessie) includes Python 3.4.
• CentOS 7 and RHEL 7 includes Python 2.7 and Python 3.6 can be installed from the Software Collections (SCL).
• CentOS 6 and RHEL 6 includes Python 2.6 and Python 2.7.
• Fedora 28 and earlier versions typically included Python 3.6 or earlier.
• Arch Linux generally provides the latest version of Python, but older installations may have Python 3.6 or earlier.
• openSUSE Leap 15.0 includes Python 3.6.

[rhc54]

FWIW: my CI uses "ubuntu-latest", and the web reports that defaults to Python 3.10. So there have been some syntax changes between 3.10 and 3.12 - sigh. Anyway, I can at least confirm that PMIx/PRRTE can successfully build from git clone at 3.10. Don't know about earlier.

[jsquyres]

FWIW: my CI uses "ubuntu-latest", and the web reports that defaults to Python 3.10. So there have been some syntax changes between 3.10 and 3.12 - sigh. Anyway, I can at least confirm that PMIx/PRRTE can successfully build from git clone at 3.10. Don't know about earlier.

As part of this PR, I confirmed that the entire Open MPI main branch -- including the submodules where they currently point -- builds correctly from scratch with Python 3.7.17 (i.e., the latest Python 3.7.x).

[rhc54]

Yeah, I can believe that - but your submodule pointers are (a) woefully out of date and (b) don't point to PRRTE master. So I can't use that data point as it doesn't cover my show-help conversion scripts.

[jsquyres]

I just build openpmix and prrte master (outside of an OMPI tree) on Alma 9 with a hand-compiled Python 3.7.17 and it all worked fine (I did have to edit the OAC in prrte to not check pmixcc with --showme:libs_static). I also hand-ran the show help conversion scripts in pmix and prrte with Python 3.7.17 just to be sure, and those worked fine.

[rhc54]

Kewl - I just built a container with Rocky Linux and hand-built Py 3.7.17 and it all built there too.

I did have to edit the OAC in prrte to not check pmixcc with --showme:libs_static

I do have a PR on OAC to fix something - not sure if this is related or not as I've honestly forgotten what I did in that PR (been too long). Is this something that needs to be fixed? If so, perhaps you can post the change?

[jsquyres]

I do have a PR on OAC to fix something - not sure if this is related or not as I've honestly forgotten what I did in that PR (been too long). Is this something that needs to be fixed? If so, perhaps you can post the change?

I really did hack it -- I did not make a correct fix. 😄

This is the prrte error that comes up:

checking for pmix wrapper compiler static ldflags... error
configure: error: An error occurred retrieving pmix static ldflags from wrapper compiler

Because PRTE is calling OAC which is checking pmixcc --showme:libdirs_static, and pmixcc doesn't support that particular flag. I just hacked the OAC in prte to not check that flag, simply so that I could test the python stuff.

[rhc54]

Because PRTE is calling OAC which is checking pmixcc --showme:libdirs_static, and pmixcc doesn't support that particular flag.

Okay - so were you configuring as static or something? I'm asking because I've never seen that error, so I'm wondering if this is something that has always existed but not surfaced until you built a particular way.

[jsquyres]

Okay - so were you configuring as static or something? I'm asking because I've never seen that error, so I'm wondering if this is something that has always existed but not surfaced until you built a particular way.

Not as far as I know. I configured both pmix and prte with:

./configure --prefix=/home/jsquyres/bogus

My alma9 VM has hwloc and libevent devel RPMs installed. /home/jsquyres/bogus/bin is in my PATH and /home/jsquyres/bogus/lib is in my LD_LIBRARY_PATH, so I don't have to specify pmix's location to prte's configure script.

If this is going to turn into a prte/pmix debugging session, we should probably move off this ticket. 😄

[rhc54]

Sounds good. Given that's the standard configure line used pretty much everywhere, I'll chalk this up as "anomalous" and set it aside until someone reports it over here.