PythonScriptBridge hardcoded Python path

mhisted's Avatar

mhisted

12 Apr, 2016 06:05 PM

Hi Chris,

We are still using the PythonScriptBridge window in the client, because it makes life easier for many of our users. (Ultimately we'll shift to a python server bridge in a terminal window, but not immediately).

From what I can see on github, it seems that the python executable path is hardcoded to /usr/bin/python2.6.

I'd prefer to use the system python2.7 (In particular, because you can use easy_install --user with 2.7 and not 2.6, and SIP doesn't allow easy_install without --user to modify system directories). And in the future I may try to use a python from anaconda.
Is there an easy way to change the python executable path? Right now I'm planning to disable SIP and just rename it in /usr/bin.

Thanks,
Mark

  1. Support Staff 1 Posted by Christopher Sta... on 12 Apr, 2016 06:22 PM

    Christopher Stawarz's Avatar

    Hi Mark,

    MWClient's Python bridge is hardcoded to use /usr/bin/python2.7 (and has been for several years). Why did you think it was invoking Python 2.6?

    And in the future I may try to use a python from anaconda.

    Adding support for alternative Python interpreters has been on my to-do list for quite a while, but so far there's been no demand for it. I'd be happy to bump it up the list, if you think you'll want it in the near future.

    Cheers,
    Chris

  2. 2 Posted by mhisted on 12 Apr, 2016 06:53 PM

    mhisted's Avatar

    > MWClient's Python bridge is hardcoded to use /usr/bin/python2.7 (and has been for several years). Why did you think it was invoking Python 2.6?
    >

    Because I was looking at a very old github repository:
    https://github.com/mworks-project/mw_client_plugins/blob/master/PythonBridgePlugin/PythonBridgeController.m

    I noticed that I had gotten this wrong soon after sending, sorry for not updating you.

    >
    > And in the future I may try to use a python from anaconda.
    >
    > Adding support for alternative Python interpreters has been on my to-do list for quite a while, but so far there's been no demand for it. I'd be happy to bump it up the list, if you think you'll want it in the near future.
    >

    If I understand correctly, if we launch ourselves the python process running the bridge, we can use any interpreter. Is that right? If so, it's probably not worth your time to change as we'll eventually go to a server bridge running in a terminal.

    The system python has numpy, but not scipy, so it's not ideal for plotting as scipy is a real bear to install from source.

    Mark

  3. Support Staff 3 Posted by Christopher Sta... on 13 Apr, 2016 02:20 PM

    Christopher Stawarz's Avatar

    If I understand correctly, if we launch ourselves the python process running the bridge, we can use any interpreter. Is that right?

    I think that was sort of true in the past, but it's not any more.

    It shouldn't be too big of a job to add support for different interpreters. I'll try to get it done in the relatively near future.

    Chris

  4. 4 Posted by mhisted on 13 Apr, 2016 09:06 PM

    mhisted's Avatar

    Thanks. Just out of curiosity, what is the issue that prevents using different python versions on the other side of the bridge?
    I thought they communicated only via a pipe/socket?

    Have a good day,
    Mark

  5. Support Staff 5 Posted by Christopher Sta... on 15 Apr, 2016 02:41 PM

    Christopher Stawarz's Avatar

    Hi Mark,

    Just out of curiosity, what is the issue that prevents using different python versions on the other side of the bridge?

    We discussed this offline, but I'll answer here, too, for the benefit of the archive:

    MWorks' Python package includes a C++ extension module (/Library/Application Support/MWorks/Scripting/Python/mworks/_mworks.so) that is compiled against the OS X system Python (version 2.7). Prior to Python 3.2, Python's developers made no guarantee of binary compatibility between major releases. This means that MWorks' extension module would need to be compiled separately for every Python release we wanted to support. While that isn't an insurmountable obstacle, our usage of Boost.Python complicates things a bit, and since no one has been requesting support for alternate Python versions, I haven't pursued it.

    Python 3.2 and later provide an opt-in method of ensuring that extension modules compiled for one version remain compatible with later ones. However, we won't be able to take advantage of that unless we drop support for Python 2.7, which I don't see happening soon. (Also, Boost.Python is again likely to complicate things.)

    Cheers,
    Chris

  6. Christopher Stawarz closed this discussion on 13 May, 2016 12:38 AM.

  7. Christopher Stawarz closed this discussion on 30 Oct, 2019 02:09 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