siclark wrote:The usr/bin version sounds like it's installed with xcode and is a higher version than the standard 3.1. ?
Ah, yes, I forgot there's yet one more thing that can install Python...
siclark wrote:Is there anyway to specify the version to use?
It's always the most safest to be explicit in the path to the executable. There are tradeoffs though:
- /Library/Frameworks/Python.framework/Versions/3.10/bin/python3 - this is the most explicit way to start up the 3.10 interpreter. The downside is that when we (eventually) upgrade to Python 3.11, using this will then point to the wrong version
- /usr/local/bin/python3.10 - this is a symlink to the above option, and has the same downside. In addition, though, since it's a symlink in a more public directory, it could get updated by something else entirely.
- /Library/Frameworks/Python.framework/Versions/Current/bin/python3 - this option will overcome option 1's downside because the python 3.11 installer will change the Current component (which is a symlink) to point to the 3.11 install. The downside to this is that if you (for some reason) install an older version, the installer might update that link to point to the older version.
- /usr/local/bin/python3 - this option is created/maintained by the python installer as well, so it has the same benefits/issues of the last option, but also since it's a symlink it could get munged by some other installer (homebrew/macports).
So, there is no completely foolproof solution. I tend to use option 3 above on my production Mac, because I never do a Python install outside of Indigo. However, I tend to use #1 above on my dev Mac because I often need multiple versions of Python installed for different scenarios and I want to be as explicit as possible.
siclark wrote:Or is there a more indigo specific way to have the image generation running in a separate process that won't interfere with the rest of the plugin?
TBH, I don't really understand the issue. You say:
I can run the code in a normal method, but then the whole of indigo hangs when it tries to run whilst I have an edit device window open, so I am back to trying to make it run as a subprocess.
but I don't understand 1) why you would be generating an image while a dialog is open and 2) why the image generation is taking so long. So without more understanding, I can't really say if there's a better way. I would recommend taking a step back and think about the higher-level architecture of the plugin. There are almost always multiple ways to skin a cat, and it's entirely possible that a different approach would yield better results.