Adding a json config users can provide to configure service

[wvangeit]

I think the user-experience might improve if some things can be configured by the user, so that the run involves less implicit rules.
I would propose to introduce a file, e.g. '.osparc-pyrun-config' that users can store in the zip file (if there is no zip file involved, or no config file, we fall back to the old behavior)

• A version number of the format (so that we can upgrade later and break compatibility)
• the location of the script the user wants to let python run (not required)
• the location of the requirements file (not required)
• the 'working' dir of python (i.e. where to run the python command from) (not required)

(In the future I could see other options like: 'store env cache after requirements are installed', 'change python command used', etc.)

'location' would be a path relative to the location of the json config file. Only 1 file allowed.

@pcrespov @sanderegg @newton1985 what do you think? Just asking before I begin implementation.

[pcrespov]

I like the idea of adding these configuration options. Having it in some sort of config also fits POLA

THOUGHT:
I would nonetheless recall that the service ports is the "standard setup mechanism" for a service. In the old days of sim4life we had not only ports (inputs/ouputs) but also settings for a "service". This proved to be a limiting feature since inputs/outputs could be interconnected but not settings. We actually noticed that settings can be defined as inputs as well. Inputs that can be set with a constant value or eventually injected from the output of another service.

Moreover, having config files (or in general files as inputs) hides information from the framework and which limits the ability of the framework to e.g. validate ports

[wvangeit]

@pcrespov I agree with you wanting the ability to provide the settings as ports. I don't think one excludes the other. We could still add some procedures for ports to provide overrides on the options specified in the json file from the osparc web interface etc. But at least the 'standard' json file can be stored in a git repository etc.

Wrt to hiding ability. Yes, that's indeed a bit of concern. I wonder if there could be some mechanism for the framework to peak into these json files.