Subworkflows are not checked for dependencies within Groups

[rexissimus]

Example: A subworkflow with a spreadsheet module inside a Group will fail to load if it is loaded before the spreadsheet package.

If this happens the abstraction package needs to be manually reloaded to enable the subworkflow.

[remram44]

I don't understand this -- do you mean that opening a pipeline that contains an abstraction module, the abstraction's pipeline is checked for needed packages? But that doesn't recurse in the abstraction pipeline's groups?

Or is it when opening the abstraction's pipeline in the view?

[rexissimus]

This is when subworkflows in ~/.vistrails/subworkflows/ are loaded when starting vistrails.

[dakoop]

I think those subworkflows are loaded after all packages (including the spreadsheet). So the case in question is when the spreadsheet is manually loaded after starting VisTrails, right? The right way to do this is probably to have a hook so that whenever a package is (re)loaded, we check all subworkflows to see which may need to be (re)loaded. Ideally, the packages each subworkflow depends on should be cached to make this a quick check.

[rexissimus]

This all happens at startup. Loading the subworkflows last should fix this. I checked if this was already done but could not find it. Maybe checking for dependencies at the top level was considered good enough?

[remram44]

On my machine, this triggered a VistrailsInternalError("No package is currently being loaded and argument 'package' is not specified.") (from add_module_from_settings()) once. Loading a workflow with a missing abstraction also completely fails with:

Traceback (most recent call last):
  File "vistrails\gui\collection\workspace.py", line 927, in item_selected
    open_vistrail(locator, **args)
  File "vistrails\gui\vistrails_window.py", line 1730, in open_vistrail_without_prompt
    view = self.open_vistrail(locator, version, is_abstraction)
  File "vistrails\gui\vistrails_window.py", line 1619, in open_vistrail
    is_abstraction):
  File "vistrails\core\application.py", line 410, in open_vistrail
    *loaded_objs[1:])
  File "vistrails\gui\application.py", line 314, in add_vistrail
    return self.builderWindow.add_vistrail(*objs)
  File "vistrails\gui\vistrails_window.py", line 1579, in add_vistrail
    view = self.create_view(*objs)
  File "vistrails\gui\vistrails_window.py", line 940, in create_view
    thumbnail_files, mashups)
  File "vistrails\gui\vistrail_view.py", line 124, in __init__
    pipeline_view=pipeline_view)
  File "vistrails\gui\vistrail_controller.py", line 175, in __init__
    auto_save)
  File "vistrails\core\vistrail\controller.py", line 200, in __init__
    set_log_on_vt=set_log_on_vt)
  File "vistrails\core\vistrail\controller.py", line 252, in set_vistrail
    self.ensure_abstractions_loaded(self.vistrail, abstractions)
  File "vistrails\core\vistrail\controller.py", line 2413, in ensure_abstractions_loaded
    lookup)
  File "vistrails\core\vistrail\controller.py", line 2365, in check_abstraction
    '')
  File "vistrails\core\modules\module_registry.py", line 773, in get_descriptor_by_name
    package_version)
vistrails.core.modules.module_registry.MissingModule: Missing module 7998878f-edcf-11e4-ab8b-f102f92a2c09|mplthing in package local.abstractions (version 1.6)

This is all very broken.

[rexissimus]

Fixed by aea6e38

[dakoop]

@rexissimus, looks good, but there is an is_group method on core.vistrails.module.Module (and Group) that would be more appropriate than the name/package equality check.

[rexissimus]

Thanks, fixed in 9c04ab5.

[remram44]

I notice that is_group() is False for abstractions, how are subworkflows in subworkflows handled?

[rexissimus]

Subworkflows are all in the "My Subworkflows" package, so there should not be a need to recurse on subworkflows to get all dependencies.