Custom actions

[mlucool]

Fixes: #584

This adds the ability for users to set a custom class to take actions. As of now, we only have a post_init action, but this can be trivially extended to give more power to end users who have non-generic needs.

Example ~/.jupyter/jupyter_notebook_config.json:

  "JupyterLabGitConfig": {
      "custom_git_actions_class": "org.dir.MyClass"
  }

[mlucool]

I'm add to add documentation to the README and test cases if this is the right design. Thought I'd bring this up for feedback first

[fcollonval]

@mlucool Thanks for this PR. Using server configuration is safe enough - managed installation will keep control 😉

Regarding the implementation, I suggest to not be as generic for two reasons:

• We don't want to deal with complex custom Python code plugged-in
• We want to keep some control over those side-effects - like be able to implement a timeout feature around them.

So I propose to use the following configuration to a list of subprocess commands to be executed in the repository folder:

{
  "JupyterLabGit": {
    "actions": {
      "postInit": [{
        "command": Array<string>, // subprocess command
        "args": Dict[string, string]  // subprocess args
      }]
    }
  }
}

Some comments on the schema:

• Use JupyterLabGit shorter name - we know that we are speaking about configuration
• Add a subentry actions so this will allow to organize the configuration parameters - if it grows in the future
• Add actions subentry with clear name about when it is gonna be executed (e.g. you could add a postClone entry)

What do you think?

To make it works easily with Configurable, I suggest to use AutoInstance implemented in jupyter-project.

[mlucool]

Regarding the implementation, I suggest to not be as generic for two reasons:

I don't totally agree, but I'm happy to oblige. One key reason is that the API is very hard to establish - but maybe we just promise to give the script nothing and we call it in the right cwd. I also find in process error handling mostly easier. Still, we ca go with arbitary shell commands only, but I think we just support anything a user puts and use shlex to break it up or use the shell=True ( i.e. '/my/script.py --foo' is a valid command to pass).

Some comments on the schema:

These all seem reasonable

[fcollonval]

but I think we just support anything a user puts and use shlex to break it up or use the shell=True ( i.e. '/my/script.py --foo' is a valid command to pass).

Good point, this will ease the setting.

[mlucool]

@fcollonval updated. Any more feedback or I will finish cleaning this up (more doc, seeing if its easy enough to test). I can add this to places besides init (e.g. clone) as well.

[mlucool]

@fcollonval did you have further feedback?

[fcollonval]

Thanks @mlucool

I left a few questions in your proposal.

For the test, could you test also a failure of execute with a non-zero code and with the emission of an exception? This is quite critical and will help use ensuring robustness of the extension.

[fcollonval]

Opened question: Should the stdout be concatenate for all actions?

[fcollonval]

Opened question: Should stdout logged to help debugging?

[mlucool]

Do we have any examples of logging? For now, I sent all data (stdout/stderr/code/command) back to the front end where we can later show whatever we'd like to the user.

[mlucool]

@fcollonval this is ready for re-review.

For the test, could you test also a failure of execute with a non-zero code and with the emission of an exception? This is quite critical and will help use ensuring robustness of the extension.

Tested no post_init, post_init that works, and post_init that fails

[fcollonval]

@mlucool Thanks for the addition of the tests. I saw one error. And then we should be good to go.

About the logging, you can drop it for now - I'm looking into this without the need to pass a logger object from the notebook application.

[mlucool]

@fcollonval I believe all review feedback is taken care of

[fcollonval]

LGTM !
Thanks a lot @mlucool

[fcollonval]

@meeseeksdev backport to 0.11.x