Thanks! I wanted to drop the dependency on .ipynb for this version, so I went with .py files instead. The detachable kernel itself isn't tied to .py, so I'm considering a dedicated extension like .pynb (Python notebook) to distinguish notebooks from regular Python scripts in the future.
An engineering nightmare. But as a passenger, it might be nice. Can take time getting on to the container and settled, and then the whole container gets loaded.
I think the idea is a natural next step in GPU's as a service. If you can create the unifying API layer for GPU access I think that would be immensely useful.
Any reason why you also decided to go with .py files as part of your detachable kernel architecture?