Repo2docker: feature request: "editable" mode

[neuromusic]

Here's the idea...

$ cd ~/Projects/my_repo/
$ repo2docker -e ./

This launches my environment, I run my notebooks, then... oh no!! there's a bug!

I fix the bug, save the notebook (running in the repo2docker docker container), then shut down the docker container.

$ git status

The changes I saved in the docker container are applied locally! Now, I can commit them, certain that they work in the environment built by repo2docker.

[betatim]

You can currently do this with repo2docker -v .:/home/$USER . which is a bit exotic.

I thought ,until I recently tried using it, that "editable" was the default when using a local repository. Tracking down when and why that changed (or if it was just something I was imagining) would be a welcome contribution. For sure I'd support making it the default (that I thought we always had :) ).

[evertrol]

Is my assumption correct that this can changed to be done by default with the following diff:

index 73ac12c..d1f5126 100644
--- a/repo2docker/app.py
+++ b/repo2docker/app.py
@@ -389,6 +389,7 @@ class Repo2Docker(Application):
             self.repo = args.repo
             self.ref = None
             self.cleanup_checkout = False
+            self.volumes['.'] = '.'
         else:
             self.repo_type = 'remote'
             self.repo = args.repo

Thus, the -v .:/home/$USER is automatically implemented if os.path.exists(args.repo) is true.

---

A grep on volumes through the history of app.py doesn't give any indication that this behaviour was the default previously.
In that case, it may be better to add it as an option (as suggested above, -e or --edit), to prevent confusion (i.e., an if args.edit: statement just above the new line in the above diff).

[betatim]

That looks about right. Though it shouldn't be self.volumes['.'], the key has to be the actual path to the repository that is being built. I think in my example it was just a coincidence that this was ..

Unfortunately -e is already taken for environment variables so we need to invent a new short hand. Maybe -E and --editable which kinda mirrors pip install?

[evertrol]

I've backdated my comment: self.volumes['.'] = '.' actually works: the mount is relative to the jovyan user. This only deals with the right hand side.

The '.' on the left hand side follows from the example, which is run inside the directory of interest.
Probably, self.volumes[args.repo] could work, though if args.repo is a filename or has an (accidental) .git extension, some extra care needs to be taken, like:

repodir = args.repo
if not os.path.isdir(repodir):
    repodir = os.path.dirname(repodir)

I'll have a look at that, and may then turn it into a PR.

---

I was indeed thinking about -E and --editable (or --edit) as option names.

[choldgraf]

--editable sounds great toe me!

[evertrol]

I think this can be closed, now that #421 is merged.

[betatim]

Good catch! I've become super reliant on "Fixes #NNN" being mentioned in the PR's first comment which means GitHub automatically close that issue.

[evertrol]

I was going for "implements #NNN", but looking through GitHub shortcuts, there were only variants of "fixes #NNN" or "closes #NNN".
"Resolves #NNN" could have worked, but it still felt wrong for a new feature. And I wasn't going to let GitHub dictate my choice of words in this case.
(fun fact: GitLab does support "Implements #NNN".)