Supported Python versions

lafossek21's Avatar

lafossek21

03 May, 2019 04:16 PM

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

  1. Support Staff 1 Posted by Christopher Sta... on 03 May, 2019 04:24 PM

    Christopher Stawarz's Avatar

    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

  2. 2 Posted by mhisted on 04 May, 2019 10:12 PM

    mhisted's Avatar

    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

  3. 3 Posted by mhisted on 05 May, 2019 03:13 PM

    mhisted's Avatar

    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

  4. Support Staff 4 Posted by Christopher Sta... on 06 May, 2019 02:02 PM

    Christopher Stawarz's Avatar

    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

  5. 5 Posted by mhisted on 06 May, 2019 03:39 PM

    mhisted's Avatar

    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

  6. Support Staff 6 Posted by Christopher Sta... on 07 May, 2019 02:42 PM

    Christopher Stawarz's Avatar

    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

    1. it's not clear which versions I should pick (the latest, certainly, but how far back do I go?), and
    2. 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

  7. Christopher Stawarz closed this discussion on 14 May, 2019 02:32 PM.

  8. Christopher Stawarz re-opened this discussion on 30 Oct, 2019 02:08 PM

  9. Support Staff 7 Posted by Christopher Sta... on 30 Oct, 2019 02:08 PM

    Christopher Stawarz's Avatar

    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

  10. Christopher Stawarz closed this discussion on 06 Nov, 2019 02:13 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac