Issue with setuptools.build_meta not being available on z/OS with Python3.12 and Python 3.13

[bchoudhary6415]

Hello,

I'm encountering an issue while trying to build the ibm_db package using Python 3.13 on z/OS with: python -m build

bash-5.2$ python -m build
* Creating isolated environment: venv+pip...
* Installing packages in isolated environment:
  - setuptools
* Getting build dependencies for sdist...
/RS25/tmp/build-env-7omdtfuq/lib/python3.13/site-packages/_distutils_hack/__init__.py:53: UserWarning: Reliance on distutils from stdlib is deprecated. Users must rely on setuptools to provide the distutils module. Avoid importing distutils or import setuptools first, and avoid setting SETUPTOOLS_USE_DISTUTILS=stdlib. Register concerns at https://github.com/pypa/setuptools/issues/new?template=distutils-deprecation.yml
  warnings.warn(

Traceback (most recent call last):
  File "/u/.local/lib/python3.13/site-packages/pyproject_hooks/_impl.py", line 402, in _call_hook
    raise BackendUnavailable(
    ...<4 lines>...
    )
pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'

ERROR Backend 'setuptools.build_meta' is not available.

I've checked the pyproject.toml file for the ibm_db package, and the necessary configurations seem correct. The problem occurs only on z/OS. This works perfectly fine on LUW (Linux/Unix/Windows) and macOS environments.

Has anyone encountered a similar issue with Python 3.13 on z/OS? Any suggestions or workarounds would be greatly appreciated.

Thank you in advance for your assistance!

[webknjaz]

What's in setup.py?

[abravalheri]

Ok, I suppose that is what is not working then. Thank you (sorry for asking a bunch of stuff, I will not be able to replicate your system/environment, so I will need your help to debug).

The code mentions, a couple of edge cases in https://github.com/pypa/setuptools/blob/v75.8.2/_distutils_hack/__init__.py#L122-L129.

I am guessing this try...except is being reached somehow.
It would be interesting to know the details of why.

If we add some very rustic "debug statements" like the following to your /u/.local/lib/python3.13/site-packages/_distutils_hack/__init__.py file:

diff --git i/_distutils_hack/__init__.py w/_distutils_hack/__init__.py
index 94f71b99e..4f925607f 100644
--- i/_distutils_hack/__init__.py
+++ w/_distutils_hack/__init__.py
@@ -47,6 +47,7 @@ def enabled():
     Allow selection of distutils by environment variable.
     """
     which = os.environ.get('SETUPTOOLS_USE_DISTUTILS', 'local')
+    print(f"{which=}")
     if which == 'stdlib':
         import warnings

@@ -69,7 +70,7 @@ def ensure_local_distutils():
     # perform an import to cause distutils to be
     # loaded from setuptools._distutils. Ref #2906.
     with shim():
-        importlib.import_module('distutils')
+        print(f"{importlib.import_module('distutils')=}")

     # check that submodules load as expected
     core = importlib.import_module('distutils.core')
@@ -85,6 +86,7 @@ def do_override():
     for more motivation.
     """
     if enabled():
+        print("overriding")
         warn_distutils_present()
         ensure_local_distutils()

@@ -105,11 +107,13 @@ class DistutilsMetaFinder:
             return None

         method_name = 'spec_for_{fullname}'.format(**locals())
+        print(f"{method_name=}")
         method = getattr(self, method_name, lambda: None)
         return method()

     def spec_for_distutils(self):
         if self.is_cpython():
+            print("is_cpython")
             return None

         import importlib
@@ -118,7 +122,8 @@ class DistutilsMetaFinder:

         try:
             mod = importlib.import_module('setuptools._distutils')
-        except Exception:
+            print(f"{mod=}")
+        except Exception as ex:
             # There are a couple of cases where setuptools._distutils
             # may not be present:
             # - An older Setuptools without a local distutils is
@@ -127,6 +132,9 @@ class DistutilsMetaFinder:
             #   setuptools from the path but only after the hook
             #   has been loaded. Ref #2980.
             # In either case, fall back to stdlib behavior.
+            print(f"{ex=}")
+            import traceback
+            traceback.print_exc()
             return None

         class DistutilsLoader(importlib.abc.Loader):
@@ -137,9 +145,11 @@ class DistutilsMetaFinder:
             def exec_module(self, module):
                 pass

-        return importlib.util.spec_from_loader(
+        loader = importlib.util.spec_from_loader(
             'distutils', DistutilsLoader(), origin=mod.__file__
         )
+        print(f"{loader=}")
+        return loader

     @staticmethod
     def is_cpython():

What would then be the output of the same test script as in the previous comment?

[bchoudhary6415]

After doing those change, result is below

>>> from _distutils_hack import override, DISTUTILS_FINDER
which=''
>>> import sys
>>> for entry in sys.meta_path:
...     print(entry)
...
<class '_frozen_importlib.BuiltinImporter'>
<class '_frozen_importlib.FrozenImporter'>
<class '_frozen_importlib_external.PathFinder'>
>>> print(f"{DISTUTILS_FINDER.find_spec('distutils', None)=}")
method_name='spec_for_distutils'
ex=ModuleNotFoundError("No module named 'distutils'")
Traceback (most recent call last):
  File "/u/.local/lib/python3.13/site-packages/_distutils_hack/__init__.py", line 127, in spec_for_distutils
    mod = importlib.import_module('setuptools._distutils')
  File "/rsusr/pyz/3.13.0/lib/python3.13/importlib/__init__.py", line 88, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1310, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 1035, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/u/.local/lib/python3.13/site-packages/setuptools/__init__.py", line 14, in <module>
    import distutils.core
ModuleNotFoundError: No module named 'distutils'
DISTUTILS_FINDER.find_spec('distutils', None)=None

[webknjaz]

I see there are a bunch of nasty hacks happening in that project… But what I'm concerned about is that I recall the import order being important and breaking in the past: #2230 (comment).
I wonder if placing all setuptools imports before anything else (and definitely before importing distutils) would make it loadable.
It's probably worth experimenting with an empty project with just setup.py and a few lines of boilerplate to confirm that said platform isn't borked outside setuptools, though.

[abravalheri]

File "/u/.local/lib/python3.13/site-packages/setuptools/init.py", line 14, in
import distutils.core
ModuleNotFoundError: No module named 'distutils'
DISTUTILS_FINDER.find_spec('distutils', None)=None

Just for the sake of sanity check: could you please confirm the files for /u/.local/lib/python3.13/site-packages/setuptools/_distutils/* exist?

---

This is very odd. Is there any chance Python 3.12/13 on z/OS is having problems with the import machinery evaluation/partial-evaluation order?

I understand that the import machinery may try to load the setuptools module before setuptools._distutils module (and setuptools itself imports distutils, which is "redirected to" setuptools._distutils byt _distutils_hack), but that should be completely fine, otherwise stuff like from . import module in __init__.py files would always fail, and we know that to not be true. The relevant bits of the Python docs seem to indicate this behaviour is OK:

The module will exist in sys.modules before the loader executes the module code. This is crucial because the module code may (directly or indirectly) import itself; adding it to sys.modules beforehand prevents unbounded recursion in the worst case and multiple loading in the best.

If loading fails, the failing module – and only the failing module – gets removed from sys.modules. Any module already in the sys.modules cache, and any module that was successfully loaded as a side-effect, must remain in the cache. This contrasts with reloading where even the failing module is left in sys.modules.

And we know for sure this approach works in macOS/linux/windows...

I don't know, I think I am way out of my area of expertise here.

[bchoudhary6415]

@abravalheri @webknjaz
Thank you so much for your help!