Valerio Viperino
vvzen
About Me
EXPERTISE
Developer
INDUSTRY
Advertising / Motion Graphics
Houdini Skills
Availability
Not Specified
Recent Forum Posts
houdini/houdinifx 19.0 python wrappers are broken in Monterey Sept. 21, 2022, 4:38 a.m.
johnmatherGreat to know!
This issue was resolved in 19.0.562.
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.
houdini/houdinifx 19.0 python wrappers are broken in Monterey Sept. 20, 2022, 10:04 a.m.
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:
Actual behaviour:
The issue here is that the shebang used is
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
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
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) :
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
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:
$ open /Applications/Houdini/Houdini19.0.561/Utilities/Houdini\ Terminal\ 19.0.561.app
$ cd /Applications/Houdini/Houdini19.0.561/Frameworks/Houdini.framework/Versions/Current/Resources $ source houdini_setup_bash
Try to run 'houdinifx' from the terminal.
Actual vs expected behavior
Expected behavior:
houdinifxstarts fine from the shell session.Actual behaviour:
$ houdinifx -bash: /Applications/Houdini/Houdini19.0.561/Frameworks/Houdini.framework/Versions/Current/Resources/bin/houdinifx: /usr/bin/python: bad interpreter: No such file or directory
The issue here is that the shebang used is
#!/usr/bin/python:$ cat /Applications/Houdini/Houdini19.0.561/Frameworks/Houdini.framework/Versions/Current/Resources/bin/houdinifx | grep python #!/usr/bin/python
But python2 has been deprecated since Monterey 12.3.
As matter of fact, on a new clean system (without user aliases):
$ which python
$ which python3
/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:
$ cd /Applications/Houdini/Houdini19.5.303/Frameworks/Houdini.framework/Versions/Current/Resources
$ which houdinifx
/Applications/Houdini/Houdini19.5.303/Frameworks/Houdini.framework/Versions/Current/Resources/bin/houdinifx
$ houdinifx
Valerio
Current Status on Apple Silicon Aug. 3, 2022, 6:43 a.m.
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
