I was looking at the documentation and the implementation of the options_form and options_from_form, on the example of the DockerSpawner, and the implementation right now feels like it is more complicated than necessary. I might be overlooking something, this is why I thought posting it as a question rather than an issue is a good start.
Right now in order to implement custom options one needs to do the following:
- Define the form that reads these options
- Parse the user provided options into the
Spawner.user_optionsdictionary using a generic function. - Modify the behavior of the spawner.
dockerspawner.DockerSpawner itself has an implementation of options_form which:
- Reads the
"image"from the form and puts it intouser_options - The
start()method checks whether the image is in the list of allowed images and assignsself.imagebefore proceeding with the rest of the actions.
Similarly, the DemoFormSpawner example parses the options and overrides LocalProcessSpawner.get_args and LocalProcessSpawner.get_env.
In other words, implementing options form requires implementing an arbitrarily powerful function as well as overriding spawner behavior by subclassing.
I wonder whether it makes sense to simplify using option forms by letting options_from_form generate the spawner config, which would be assigned to the spawner after being returned from options_from_form. This would allow to arbitrarily change the spawner configuration without subclassing, while still requiring subclassing to change the spawner behavior (just like it is now).
This could be done in a backwards-compatible way by implementing a new function config_from_form.
Does this idea make sense? Am I missing something?