Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python Import Error on macOS after upgrading to E+ 24.2.0a #5281

Closed
jmarrec opened this issue Oct 29, 2024 · 4 comments · Fixed by #5287
Closed

Python Import Error on macOS after upgrading to E+ 24.2.0a #5281

jmarrec opened this issue Oct 29, 2024 · 4 comments · Fixed by #5287

Comments

@jmarrec
Copy link
Collaborator

jmarrec commented Oct 29, 2024

Issue overview

The Run_RubyPythonPlugin test is failing. This is a codesigning issue, so mac only. It happens when you try to run the "PythonPlugin" feature of E+.

Current Behavior

https://ci.openstudio.net/blue/organizations/jenkins/openstudio-incremental-osx/detail/PR-5252/2/pipeline#step-84-log-42

Expected Behavior

It should work.

Possible Solution

Basically this is because E+ has codesigning on macOS, and it does not have a specific entitlement that allows to load unsigned (or differently signed) library at runtime (via dlopen).

The E+ exe is signed, the libpython is signed, all with the EnergyPlus codesigning certificate.
We pip install some dependencies that have a native extension, at least numpy and pandas. these are NOT signed. So it fails at runtime

Possible solutions:

  • Rebuild an E+ package that adds an entitlements to allow this specific use case. I think it's the com.apple.security.cs.disable-library-validation one based on some preliminary testing
  • Implement Codesign on macOS #5235 and override the signature with OpenStudio's
  • Remove the E+ package signing altogether (via CmakeLists, after downloading it)

Details

Environment

Some additional details about your environment for this issue (if relevant):

  • Platform (Operating system, version): macOS
  • Version of OpenStudio (if using an intermediate build, include SHA): develop

Context

Originally posted by @jmarrec in #5242 (comment)

Found again in #5279

@kbenne
Copy link
Contributor

kbenne commented Oct 29, 2024

I like option 2, implement code signing. That said, we have a lot of binaries, can we track them all down to get them signed? @wenyikuang this is your department.

@DavidGoldwasser
Copy link
Collaborator

I don't have a preference, although at some point in future, I'm hoping we can have more integrated CI through UO > OS > E+ where we can work off of develop of each tool vs. waiting for a release. Hoping to catch things before they get into develop. This may be irrelevant. to which approach we take, but I thought I'd point it out incase it wasn't.

@jmarrec
Copy link
Collaborator Author

jmarrec commented Oct 29, 2024

Codesigning is the logical choice really. Problem is, I estimate about 20-40 hours of work (based on my experience setting it up for E+ and OSApp), assuming we realdy have an Apple certificate for OpenStudio available. So that's going to be problematic to get it into 3.9.0 probably.

@DavidGoldwasser
Copy link
Collaborator

I'll tag this as 3.9 so it is in project board and we can talk about it internally on iteration call tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants