[vistrails-dev] [vistrails-users] Running modules in parallel

Rémi Rampin remi.rampin at nyu.edu
Tue Jan 7 12:32:21 EST 2014

2014/1/7 Ryan Danks <Ryan.Danks at rwdi.com>

> After some debugging what seems to be the problem is that now that the
> python.exe and pythonw.exe executables have moved out of C:\Program
> Files\Vistrails\vistrails, when sub-processes are launched they do not have
> that folder included in sys.path and as such when the new processes run  my
> package's __init__.py file they can't find the vistrails.core module,
> causing the crash. My current workaround is to wrap the first attempt at
> importing from vistrails.core in a try/except block. That way if an
> ImportError exception is thrown, I can manually add the folder to sys.path
> and retry the import. (See Below)
> try:
>     from core.configuration import ConfigurationObject
> except ImportError:
>     import sys
>     sys.path.append("C:\\Program Files\\VisTrails\\vistrails")
>   from core.configuration import ConfigurationObject

Hi Ryan,

This move is intentional. The inner 'vistrails' directory should NOT be in
sys.path. VisTrails's modules should now be imported with a 'vistrails.'
prefix, for example 'vistrails.core.configuration'.

We have some logic in VisTrails to allow the old import directives to keep
working, as we understand that it will take time for packages to
acknowledge this change. Unfortunately that logic isn't used by the new
process that multiprocessing creates.

Can you confirm whether this issue still happens if you use the
'vistrails.' prefix in your imports?

Thank you for your feedback

Rémi Rampin
VisTrails developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vistrails.org/pipermail/vistrails-dev/attachments/20140107/c5eb03d5/attachment.html>

More information about the vistrails-dev mailing list