Valerio Viperino

johnmather
This issue was resolved in 19.0.562.

Great to know!

In their replies, support told me:

Side Effects Support Ticket: #127553

Hello,

Anything above 19.0.589 should just work.

so I went with 19.0.720, and I can see the wrappers are back to being simple bash scripts.

Hi all!
I also wrote a bug report (#127553), but I thought of sharing it here too for visibility, in case it saves other macOS users some time.

To reproduce this, get access to a computer with macOS Monterey 12.3+ installed.

Open a terminal with the houdini env set up:
Or, in alternative, set up the Houdini env via the dedicated script:

Try to run 'houdinifx' from the terminal.

Actual vs expected behavior

Expected behavior: houdinifxstarts fine from the shell session.

Actual behaviour:

The issue here is that the shebang used is #!/usr/bin/python:


But python2 has been deprecated since Monterey 12.3.
As matter of fact, on a new clean system (without user aliases):
will return nothing, and

will return /usr/bin/python3.

For reference, see:
- https://developer.apple.com/documentation/macos-release-notes/macos-12_0_1-release-notes [developer.apple.com]
- https://www.macrumors.com/2022/01/28/apple-removing-python-2-in-macos-12-3/. [www.macrumors.com]

This means that there's no longer a /usr/bin/pythoninstall bundled with Monterey 12.3+. As such, using it in a wrapper script is bound to fail.
The interesting thing is that this bug happens also with the version of houdini 19 that uses python3 internally.

To reproduce this behavior, I tested different combinations (still for 19.0.561) :

• macOS build for py3
  houdinifx is still a python script using #!/usr/bin/python. Tested in houdini-19.0.561-macosx_x86_64_clang11.0_10.15
  
• macOS build for py2
  houdinifx is still a python script using #!/usr/bin/python. Tested in houdini-py2-19.0.561-macosx_x86_64_clang11.0_10.15
  
• linux build for py3
  houdinifx is a bash script (houdini-19.0.531-linux_x86_64_gcc9.3/houdini/bin/houdinifx)
  
• linux build for py2
  houdinifx is a bash script (houdini-py2-19.0.561-linux_x86_64_gcc9.3/houdini/bin/houdinifx)
  

As a quick hotfix, you guys could at least fix the python3 build for 19.0.561 and make the houdinifx wrapper script use python3 instead. This build should however be marked as non compatible with Monterey 12.3+.

Of course, houdinifx can still be run directly by avoiding the python wrapper that runs houdini/houdinifx, but I believe this issue should be addressed since "by default" the "houdini terminal" workflow is not compatible with recent macOS versions.

It's worth nothing that in 19.5.303 this behavior has changed and 'houdinifx' is just a bash wrapper, so this works fine once again:



Valerio

strangedays
How is it possible that Blender foundation can transition so quickly and Sidefx can't.

https://youtu.be/ybXPYjh0FKU?t=181 [youtu.be]

Was Craig mistaken? He said most apps can be updated in days, even if he is painting an overly rosy picture and it takes weeks or worse a month or two, we should have a native apple silicon version of Houdini a full year later.

Maybe Houdini is over complex, but Blender is beginning to do things that Houdini can do, it's free, and is already runs native.

I need to dedicate more time to Blender, it's crazy to me the things those guys can accomplish.

Blender isn't even following the VFX reference platform (https://code.blender.org/2022/02/vfx-reference-platform) so it doesn't really set a great example in terms of following good practices. So yes, it might be able to freely jump around and move faster but it does it at the price of not following any of the VFX standards for building software in a consistent environment (which helps studios deal with the related complexity of handling dependencies). It takes time to do things "the good way" and not "the quick way".

The complexity of any software product is always tied to at least 2 things, internal code base and external dependencies used. In the example video extract that you posted, it's clear that Craig is showing a fully native Swift app. Things get extremely more difficult and intertwined when writing anything that uses C/C++ libs