--editable option is not compatible with --no-run

repo2docker command fails when using both --editable and --no-run options simultaneously.

$ jupyter-repo2docker --no-run --editable .
To Mount volumes with -v, you also need to run the container

I believe that the solution would be to check whether args.run is True before executing this line:

https://github.com/jupyter/repo2docker/blob/f18835fd061911fefab0a792defb2cb990fada67/repo2docker/__main__.py#L238

I can confirm that this solution works, but I haven checked if it can have any further consequence in other scenarios.

[csala]

This means that we need to be a bit careful when we apply our Python user brain in terms of semantics.

I totally agree with that. That was the original of my confusion here!

I think it would be worth opening a Pull Request to add this feature or at the very least explore what kind of stuff breaks/happens when we try.

Alright. I’ll do that.

You can specify --user as a argument to set the username to what you want it to be. On mybinder.org we set it to jovyan. When running repo2docker locally we use the UID and name of the person executing it as it helps with file permissions etc.

Oh, I had missed this! Thanks for pointing it out. It, indeed, solved my problem.

[csala]

Ok, after investigating it a bit deeper I see that I assumed something else which is not really true, so I’ll explain my use case to see if we can figure out what to do:

What I want to achieve is the following: I have a python package which might be used from a notebook and I want to distribute a docker image that allows running a notebook already configured to use it.

The requirements are:

• solution should be self-contained and runnable offline.
• execution should be just a couple of docker commands.

repo2docker is an excellent solution, as I can:

• build an image of my repo using repo2docker: jupyter-repo2docker --no-run --image-name my-project .
• save the image: docker save -o my-project.tar my-project
• distribute the my-project.tar file

And in the receiving end I do:

• load the image: docker load -i my-project.tar
• run the image: docker run -p8888:8888 my-project

Now a new requirement shows up: The source code needs to be editable while running jupyter. So, instead of distributing only the image, I want to distribute the source code of the project alongside the image and mount the source code path as a volume so that it’s visible and editable from within the container.

And this is what I thought --editable was for, installing the project in editable mode, and why I wanted to use it alongside --no-run, because I won’t be running the image at build-time but later on.

So I ended up figuring out that the things that I really need are:

1. Install in the code in editable mode. For this, I have to add a -e to this line:

https://github.com/jupyter/repo2docker/blob/f18835fd061911fefab0a792defb2cb990fada67/repo2docker/buildpacks/python/__init__.py#L74

1. Mount the code volume when I execute the image:

docker run -p8888:8888 -v $(pwd):/home/my_user my-project

The last step is actually optional, as if I skip it the project works equally well, and code can even be edited from within jupyter.

The actual questions here are:

• Could the -e flag be added permanently on that line, or should it be optional? I think it would make no harm to make it permanent.
• If it has to be optional, should it be related to the --editable flag? I think it should, because otherwise the source code is not really editable anyway (because changes won’t be actually applied).
• If it has to be related to the --editable flag, then --no-run should be made to work alongside it.
• (new thing): Currently the project ends up inside /home/username, which is not the ideal thing if later on a different user has to mount a volume at that path once the image has been distributed. Perhaps a generic path (/home/ubuntu or /app) would be better? Or even make it optional?