Version 0.16.1 crashes python

[cheginit]

I think, probably due to some build-time issues, the new version crashes python. You can reproduce by just creating a new environment that only has swmm-toolkit and try importing it.

Also, I tried fixing the conda-forge issue but it fails to build swmm for python 3.13+. Please check that one out too.

[cheginit]

For the build-time issue, an issue can be related to the fact that in the new build system, swmm-solver folder is not bundled with the source file.

[karosc]

@cheginit, what platform are you on? Windows wheel and linux is working fine for me on python 3.13

[karosc]

For what it's worth, take a look at the build pipeline: The wheels were built, installed, and tested in all platforms using cibuildwheel

https://github.com/pyswmm/swmm-python/actions/runs/19471315319

[cheginit]

Interesting. I'm on Apple Silicon. I can run 0.16.0 just fine, but it crashes with 0.16.1.

[michaeltryby]

@cheginit I was able to test swmm-toolkit v0.16.1 on Apple Silicon ...

It appears to be working for me. That is, after I repaired my Python installation by ad-hoc signing unsigned native libraries. This is because Mac OS running on Apple Silicon enforces more strict System Integrity Protection (SIP) than when running on Intel. A SIP related failure manifests as a Python hard crash (not very user friendly).

This does not explain, however, why you can run v0.16.0 and not run v0.16.1, unless you recently switched from Mac Intel to Mac arm.

I use Conda to manage virtual environments and created a utility script to repair them. You can find it here

Hopefully, this information is helpful to you and perhaps someone else with a similar problem.

[karosc]

@michaeltryby, 0.16.1 is the first version that uses the stable abi. Is this because we bundle openmp with the wheel, which is compiled by cmake only for darwin? I guess we've always distributed the libswmm5.dylib though.

[michaeltryby]

Hey @karosc. It's more of a "Python" problem on Mac than a "swmm-toolkit" problem. Conda Python installs a lot of unsigned native libraries.

I have been using swmm-toolkit on Intel Mac with OpenMP for a long time and never experienced this issue until I switched over to Apple Silicon. It seems that SIP is more strict running on Apple Silicon than on Intel for some reason.

I tried running swmm-tookit v0.16.0 on Python v3.11 but I ran into the same issue with SIP causing an apparent Python crash. Again ad hoc signing fixed the problem.

[cheginit]

@michaeltryby I use pixi for env management, which uses uv for installing deps from PyPi. So, the issue is not related to conda. It used to work fine up to 0.16.1 release. Also, I was able to fix the conda-forge building issue (noted in my first comment) on all platforms without the ad-hoc fix for osx-arm that you mentioned. So, I'm guessing something in there's an issue with the cbuildwheel config? Since conda-forge builds from source and it built the wheels correctly.

[michaeltryby]

@cheginit Thanks for getting back in touch! Running on Mac OS can be tricky. I think we are dealing with two separate issue -- build time failures and run time failures. You and others have reported problems building the wheel from the source distribution and we also have reports that pyswmm and swmm-toolkit crashing Python on osx-arm. We are preparing a new release that includes patches for build time issues.

I maintain that the runtime issue is related to SIP on Mac OS. Using pix/uv or conda for env management doesn't matter. What matters is if Python is running unsigned native libraries or not. Our Python wrapper and swmm5 native libraries packaged in the swmm-toolkit wheel are NOT signed. You need to ad-hoc sign them to run them on osx-arm.

We will be releasing an update shortly -- v0.16.2. Please try the build and run after ad-hoc signing and let us know if it works for you.

[cheginit]

I think I found out the issue on osx-arm builds. The build uses export NO_STABLE_ABI=true, which triggers the set(SOABI ".${Python3_SOABI}") branch. But CMake's FindPython3 with Development.Module (line 26 of the root CMakeLists.txt) doesn't reliably populate Python3_SOABI on osx-arm, so it's always empty, affecting Python build on osx-arm by adding an extra . to the outputs, i.e., _solver..so and _output..so. The offending line is here:

swmm-python/swmm-toolkit/src/swmm/toolkit/CMakeLists.txt

Lines 29 to 32 in af909e4

	if(_abi_val STREQUAL "1" OR _abi_val STREQUAL "true")
	set(PY_LIMITED_API_DEF "")
	set(SOABI ".${Python3_SOABI}")
	endif()

Which would need to change to:

if(_abi_val STREQUAL "1" OR _abi_val STREQUAL "true")
    set(PY_LIMITED_API_DEF "")
    if(NOT Python3_SOABI)
        execute_process(
            COMMAND ${Python3_EXECUTABLE} -c
                "import sysconfig; print(sysconfig.get_config_var('SOABI') or '')"
            OUTPUT_VARIABLE Python3_SOABI
            OUTPUT_STRIP_TRAILING_WHITESPACE
        )
    endif()
    set(SOABI ".${Python3_SOABI}")
endif()

[cheginit]

@karosc @michaeltryby I can open a PR with this fix and also include a test in CMake using CTest for regression testing.

[michaeltryby]

@cheginit Thank you for tracking this down. A PR would be greatly appreciated. 🙏

[cheginit]

@michaeltryby and @karosc thanks for merging the PR. Whenever, you released a new version with this fix, please ping me so I can update the conda-forge version as well.