dependencies correction for py-enable

[jjstickel (Jonathan Stickel)]

In the last update to the py-enable portfile, I added dependencies for wxpython and pyqt4. These are not needed, as it already depends on pyface via traitsui, and pyface has the dependencies on wxpython/pyqt4. I will add a patch to remove the dependencies for py-enable. Sorry about the noise; a bit of oversight and forgetfulness on my part (and poor documentation by enthought).

[mojca (Mojca Miklavec)]

Just in case (better double-check than do it wrong), can you please check that none of the files installed by py-enable actually link to any dylib from wxWidgets and whatever-qt-library-there-is? That is: does py-enable depend on py-pyface solely in terms of

import some-library-from-pyface

in "plain text" python script or are any compilations involved which would require a revbump of py-enable when wxPython gets updated?

I don't have the wxWidgets variant installed at the moment, but here's what I had in mind (if any library dependency would should up in any given file installed by py-enable):

> otool -L  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/kiva/agg/_agg.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/kiva/agg/_agg.so:
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 153.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.21.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0)

I don't see any Qt dependency which looks fine (honestly I wonder what the Carbon dependency is doing there) as long as that's the case for all files.

[mojca (Mojca Miklavec)]

Another question. I'm not 100% sure, but I'm wondering if a revision increase is needed or not. It's probably not absolutely needed (nothing will break if we don't add it), but maybe it's polite to increase the revision when even the default variant vanishes? Or would the buildbot build a new binary package anyway? That's a question, not a suggestion.

[jjstickel (Jonathan Stickel)]

As far I can tell, enable depends on traitsui (and pyface) by needing to import modules. Running otool on all of enable's *.so files shows nothing of interest.

I don't know much about the consequences of removing/changing variants, including the default, nor how the buildbot works. Feel free to do what you think is best regarding the revision number.

[mojca (Mojca Miklavec)]

Checking again. py-enable indeed compiles C sources. But I'm unable to find any references to wxWidgets (I would still be curious to know how to test wxWidgets in py-enable) and it complains about:

/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/distutils/system_info.py:576: UserWarning: Specified path /usr/local/include/python2.6 is invalid.
  warnings.warn('Specified path %s is invalid.' % d)
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/distutils/system_info.py:576: UserWarning: Specified path /opt/local/include/python2.6 is invalid.
  warnings.warn('Specified path %s is invalid.' % d)
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/distutils/system_info.py:576: UserWarning: Specified path  is invalid.
  warnings.warn('Specified path %s is invalid.' % d)
non-existing path in 'kiva/quartz': '/System/Library/Frameworks/Foundation.framework/Versions/A/Headers'
Could not locate executable wx-config
File not found: None. Cannot determine wx info.
abort: there is no Mercurial repository here (.hg not found)
running build

So I'm not sure how exactly it works (whether it works at all).

Independent of all that, I can commit the changes.

[mojca (Mojca Miklavec)]

Commit in r116230. I didn't close the ticket yet ... in case that you manage to find answers to my questions about how to test wxWidgets to make sure that it actually works. If you don't care or don't want to investigate any further, just let me know and I'll close the ticket.

[jjstickel (Jonathan Stickel)]

I have tested enable by running the demo script ​basic_draw.py. If I deactivate py27-pyqt4, py27-pyside, AND py27-wxpython-3.0, then I get:

$ python enable_basic_draw.py
Traceback (most recent call last):
  File "enable_basic_draw.py", line 8, in <module>
    from enable.example_support import DemoFrame, demo_main
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/enable/example_support.py", line 66, in <module>
    from pyface.qt import QtGui
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyface/qt/QtGui.py", line 4, in <module>
    from PyQt4.Qt import QKeySequence, QTextCursor
ImportError: No module named Qt

However, if any one, and only one, of the backends is activated, including wxpython-3.0, the demo runs fine with no output. So it looks like enable searches for qt4 first, but then uses wxpython if it is installed. Also, if traitsui or pyface are deactivated, I get import errors as well. So the dependency tree is simply about finding modules to import.

Does this help with your questions? Also, note that I found that wxpython-3.0 works fine for enable and chaco (via traitsui->pyface), but is buggy with Mayavi.

[cooljeanius (Eric Gallager)]

Cc Me!

[jjstickel (Jonathan Stickel)]

@mojca: Did I answer your questions above? Can you close this ticket?

[mojca (Mojca Miklavec)]

I simply need to take more time to test everything. I wanted to keep the ticket open as a reminder for me, but since I don't have sufficient time right now to check all this, I'll simply close the ticket and try to properly test all this later.