Script generator: saving script definitions

[JamesKingWork]

As a scientist, I want to be able to save a script definition for my script generator and when a user gets a version of the standalone script generator they can use this script definition.

Acceptance criteria:

• Script Definitions are saved to a sensible area
• These script definitions can be saved, bundled and reloaded in other script generator instances
• Extra requirements captured in https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Script-generator-high-level-design#how-repo-is-updatedon-start

Notes

This means the installed app has a copy of the current script defintions added to it at build time. it should update these on start of the script generator; either automatically or first asking the user (discuss and decide)

[kjwoodsISIS]

What do we mean by bundling in this context? I would be reluctant to see us spending time implementing a complex bundling mechanism if the same end could be achieved simply by manually copying a config file to the correct location (the location being documented, of course).

[JamesKingWork]

What do we mean by bundling in this context? I would be reluctant to see us spending time implementing a complex bundling mechanism if the same end could be achieved simply by manually copying a config file to the correct location (the location being documented, of course).

When I say bundling I mean that they can be made available for other standalone script generators to use. I am not sure how this is to be done we should discuss this as part of the ticket, but manually copying a config is one of those possibilities. @Tom-Willemsen understands more about what is wanted from the user side, maybe he could weigh in and give a better description.

[Tom-Willemsen]

One of the requirements for the script generator is that users can download/be given the standalone build of the script generator and run it themselves on their own computers (away from ISIS). For the script generator to display anything sensible, it needs a config file.

That config file could:

1. be bundled with the script generator as part of a build process
   • Advantage - it can all be bundled together as a single .zip file and sent to a user
   • Disadvantage - the config file may not be the most recent version - but it should at least be compatible with the script generator it was bundled with
2. be automatically downloaded from some central location (e.g. git) when the script generator starts
   • Advantage - the config is always up to date with the latest version on the central area
   • Disadvantage - we have to think about network not being up, syncing different file versions etc.
3. be manually saved to some (documented) path which the script generator looks at
   • Advantage - it's easy for us as developers, we just hard-code a path
   • Disadvantage - easy for users to accidentally save to wrong area, possibly leading to support calls. We will end up with lots of random config files on various machines with no way of tracing / updating them if needed later on.
4. ... (other ideas welcome)

This ticket needs a short focused discussion between a few people to discuss which approach we want to use, and then implement it.

[John-Holt-Tessella]

We should list use cases, here are some:

1. User can generate scripts for the instrument which will work when they get to ISIS
2. Users can use the script generator without the internet

I think bundle it in the base dir as a git repo (we have the shared scripts thingy which is available everywhere), i.e. (install dir contains app and scripts). Then on app boot it tries to update this file, it it can great otherwise it tells the user and they can continue but the dir may be out of date.

[KathrynBaker]

Just to concur with what John suggested, have a default (updated with releases of the generator), but try to update from somewhere central on running is a standard way of running such things

[ChrisM-S]

Is there a need to version the config files (and the generated python code?) so that a user script generated off site will fail in an understandable fashion if brought to ISIS a month or two later and loaded on an instrument with a more recent config?

[JamesKingWork]

Can we also ensure as part of this ticket the word config is not used in the repo to store the script definitions as it has now been phased out everywhere else as well. The script generator preference points to a directory called ScriptDefinitions