Hi Chris,
We’re using the MWorks Python package (import mworks) on Python 3 and getting some errors on import.
Here is the error:
ImportError: dlopen(/Library/Application Support/MWorks/Scripting/Python/mworks/_mworks.so, 2): Symbol not found: _PyCObject_Type
Referenced from: /Library/Application Support/MWorks/Scripting/Python/mworks/_mworks.so
Expected in: flat namespace
in /Library/Application Support/MWorks/Scripting/Python/mworks/_mworks.so
We are using python 3.5 and MWorks 0.8. (I didn’t have time to test the latest nightly - should I do that?)
Any thoughts?
Thanks,
-Paul LaFosse
Hi Paul & Mark,
MWorks 0.8 supports Python 2.7 and 3.6. The nightly build (and upcoming 0.9 release) supports 2.7 and 3.7. (Ideally, we’d support any Python 3 version, but some issues have prevented this so far.)
You’re getting this error because Python isn’t finding the version-tagged .so for 3.5, so it’s falling back on the untagged .so, which is built against 2.7 and won’t load in any Python 3 version.
Chris
Thanks, Chris, this is helpful.
We ideally don’t want to be tied closely to a single Python 3 version for this utility routine. So it would be helpful if any Py3 version could be supported, but that’s not totally high priority.
Mark
Hi Chris,
Another idea occurred to me. Would you be interested in making conda-forge packages for the ‘mworks’ package? You could then support all of py2.7,3.6,3.7.
I understand this might be something that only we would ever use. Still, it would be helpful for us.
Mark
Hi Mark,
Would you be interested in making conda-forge packages for the ‘mworks’ package? You could then support all of py2.7,3.6,3.7.
The compiled portion of the mworks package depends on (i.e. links against) the MWorksCore framework, so it doesn’t make much sense to distribute it on its own.
I still think the right solution is to make use of the Python 3 stable ABI. The main impediment to this is that Boost.Python isn’t compatible with it, meaning I’ll need to either (1) patch Boost.Python to make it compatible or (2) abandon Boost.Python altogether.
At one point, I did try patching Boost.Python, but it required a lot of changes, probably more than I want to maintain on an ongoing basis. I’m OK with dropping Boost.Python, but that will require rewriting large chunks of both the Python data tools and the embedded Python actions, which has seemed a little hard to justify in terms of the time required. But if it’s important to you, I’ll get it done.
Chris
Hi Chris,
The compiled portion of the mworks package depends on (i.e. links against) the MWorksCore framework, so it doesn’t make much sense to distribute it on its own.
In principle you could statically link or also package the MWorksCore framework, I thought - but this may be too much work.
I’m OK with dropping Boost.Python, but that will require rewriting large chunks of both the Python data tools and the embedded Python actions, which has seemed a little hard to justify in terms of the time required. But if it’s important to you, I’ll get it done.
If you think it’s too much work, that’s fine. It’s not that important to us.
thanks,
Mark
Hi Mark,
In principle you could statically link or also package the MWorksCore framework, I thought - but this may be too much work.
I don’t think I want to go down that route.
Alternatively, I could just build and distribute the Python package for more versions of Python 3. The two problems I see with this are
- it’s not clear which versions I should pick (the latest, certainly, but how far back do I go?), and
- it doesn’t help with newer versions of Python (e.g. MWorks 0.8 couldn’t have supported Python 3.7, because Python 3.7 came out after 0.8 was released).
So this doesn’t seem like a great solution, either.
If you think it’s too much work, that’s fine. It’s not that important to us.
To be clear, I want to do it. It’s just been hard to justify spending time on it versus other things. I’ll try to fit it in before the next (post-0.9) release.
Chris
Hi Paul & Mark,
As of the current nightly build, MWorks’ Python tools now support Python 3.5 and later. This was accomplished by dropping Boost.Python and using Python 3’s stable ABI, as I suggested previously. Python 2.7 is no longer supported.
Also, MWClient’s Python script bridge now lets you (actually, requires you to) specify the Python executable to launch. This needs to be done only once, as the selection will persist between sessions. It can be changed at any time, either manually or via a workspace file.
Cheers,
Chris