`molflow info` - handling exceptions when loading workflow

[avirshup]

Looks like something is wrong with the definition of parameterize_small_molecule - molflow raises an exception while loading it. Unfortunately this causes molflow info to fail.

This is not a big deal for now. But, need to test whether a bad workflow definition somewhere in the version history could cause problems when inspecting subsequent versions.

ETA: parameterize_small_molecule works fine in python 2, it only errors in Python 3. It's due to one of the more distasteful things that we do in order to mock the return values ... (see _expecting_args in functions.py)

[joseph-schaeffer]

I'm not getting that issue - could you provide replication instructions?

$ molflow info parameterize_small_molecule
Name: parameterize_small_molecule
Default Version: v0.0.1
Inputs:
- ligand: (mdt) Molecule to parameterize.
- ligand_code: '(str) 3-letter ligand code (default: UNL)'
- forcefield: '(str) Forcefield type (default: gaff2)'
- partial_charges: '(str) Partial charge calculation method (default: am1-bcc)'
Outputs:
- mol.frcmod: (File)
- mol.lib: (File)
Description: Automatically parameterize a small molecule.
Workflow_authors: not provided
Method_authors: not provided
Methods: |-
  This workflow creates amber-style parameters for a small molecule. By default, GAFF2 atom types
  are assigned with am1-bcc partial charges, but the workflow can be configured with other input
  options.
Citations: not provided
authors:
- Aaron Virshup: Autodesk Research
contributors:
- '@avirshup'
references:
- AmberTools: http://ambermd.org/#AmberTools
definitionfile: parameterize.py
keywords:
- forcefield
- small-molecule
- parameterization

The loading of the definition is needed to get the inputs/outputs fields for the info. I can certainly catch some exceptions there, but I'm not getting it showing up locally (under Python 2.7).

[joseph-schaeffer]

Or just the stdout from the error might be enough for me to trace and fix it.

[avirshup]

Yeah, realizing it's only a problem in Py3, works fine in py2 (see edit above). It's a problem with definitions.functions._expecting_args, which to be clear is a very bullshit function I created that probably needs to die.

But more generally, if there IS a syntax error in a version of a workflow definition, we would probably want to make sure it doesn't prevent molflow from examining and retrieving other, non-broken versions.

[joseph-schaeffer]

Definitely agree we need to handle it nicely - just not sure what type of exceptions are getting thrown. It's probably easy to wrap config.py:278-279 appropriately.

[avirshup]

It could potentially be almost any exception arising from a bug in the workflow definition. So we'd probably need to catch ALL exceptions, which is less than ideal. Probably this gets back to the need for a more appropriate workflow definition language. ... so probably not a short-term issue :)

[joseph-schaeffer]

Yeah; I don't want to catch everything there, but it might be reasonable. Could definitely catch SyntaxError and recover from that - but will have to think how to do so nicely vs have it error out, since a lot of things don't need the workflow to fully load to be useful (list, info).