Add plugin hook to execute commands before git pulling

[yuvipanda]

Proposed change

We write a pluggy based plugin system for nbgitpuller. The first hook would allow arbitrary command execution before the git-pulling happens.

This enables use cases where you want to pull from something other than git. But you still need git for the diffing and merging capabilities. So the solution is to:

1. Pull from original source (such as canvas, dropbox, blackboard, google drive, etc) into a hidden git repository
2. Then do nbgitpuller things from the hidden repository

This gives us proper merge resolution, without having to implement that ourselves.

Alternative options

Support pulling from alternate sources such as canvas, URLs, blackboard, etc natively. This could provide a better integrated experience, but at the cost of much higher maintenance burden. We will also have to provide diffing and merging implementations without git, which is hard.

Who would use this feature?

People who want to use solutions other than git to store their content. This discourse post outlines some uses.

(Optional): Suggest a solution

rclone lets you sync files locally from many sources - dropbox, google drive, ftp, etc. We could try get that to work for a single source with rclone, and see what plugins we need to provide.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/repo2dockerspawner-alternative-version/3584/19

[1kastner]

@yuvipanda do you know what could be done to push this topic forward?

[psychemedia]

I also still like the idea of this interaction, although if the push is to a hidden Github repo, which I take to be a private Github repo, then how does the auth work? I thought nbgitpuller was for public repos only?

[1kastner]

I understood hidden in the sense of less people are aware of the server that is hosting several temporary git repositories, and maybe most network members are shielded from accessing it by either network design or strict firewall settings - except of course the JupyterHub itself. Yet once somebody gets through the network and firewalls, the served content is public. That would be my first approach of doing it. This could be achieved by running a git server on the same server like the JupyterHub which only serves locally (listening to localhost) or a git server running on another machine but only allowing connections from the IP (range) that belongs to the JupyterHub.

I guess it is less reasonable to make the git repository private. As far as I imagine that nbgitpuller works the students could access the credentials of that git server. That in turn would make the repository less private in the sense of that it cannot be tracked who has access to the credentials.