Following code errors for me inside spawn_config() (there should be a test on this I think):

import json
import spawn
with open('example_data/example_spec.json') as fp:
    spec_dict = json.load(fp)
spawn.inspect(spec_dict)

Also as a user, I would expect to be able to do spawn.inspect(spec_dict, outfile='spawn.json', format='json') as this parallels the CLI implementation. Also would be nice to pass in config parameters as arguments as this is more natural. I don't think it's necessary to be be able to take an argument config of type ConfigurationBase as this would be more in the realms of advanced users who could use the LocalInterface class. We could go for a **kwargs approach so that signature would be:

def inspect(spec_dict, outfile=None, format='txt', **kwargs)

Also as a user, I would expect to be able to do spawn.inspect(spec_dict, outfile='spawn.json', format='json') as this parallels the CLI implementation

I don't think this is the right way to go as it muddies the interface significantly. However I'd be happy with an additional method, write_inspection which took the inspection as an argument. So the interface would be something like:

spawn.write_inspection(spawn.inspect(spec_dict), outfile='spawn.json', format='json'))

Also, the definition is flexible, allowing config to be a dict

OK - I've merged this!

On the inspect function yes I agree actually, it should always return a dict (obviously a CLI cannot return a dict so this is not valid there) and should be abstracted from the write_inspection

However, I do still feel that there should be a top-level function where config parameters are default arguments. I saw that it could be a dict, but having it as a dict obfuscates the options a little because the user's IDE won't hint and the docstrings for that function can't tell them the options. It means they have to look into the config part of the docs which may not be immediately obvious to them. It's not about code design - which is clearly good, it's about offering a top-level wrapper function that delivers maximum usability. If you look at any major python package then it generally has top-level functions with a long list of default arguments (e.g. json.load, pandas.read_csv). These don't really reflect the underlying design but offer an incredibly easy-to-use interface for the user.

Alternatively, I could implement such top-level functions in spawn-wind but leave them out of the core spawn.