Simpler Development Entry Into the Hierarchy

[russelljjarvis]

The dockerstacks hierarchy of containers could be simplified by separating development from deployment.

I frequently find myself fighting against pre installed paths of neuronunit, however there is no reason why neuronunit should be preinstalled in a development container.

The issue of path consistency could be greatly simplified, if there was a dedicated directory in the dockerstack simply called development, and a different one called deployment. The development child container would differ to its parents, only in that anything scidash was basically not installed, under the assumption that those paths will by mounted by the developer, therefore avoiding preinstallation path conflicts.

Ie installation of the scidash components is an easy task that can occur in a deployment container. However, the usual practice for a developer is to mount their own directory dev or in my case git from the host -> container. dev contains two sub directories neuronunit and sciunit.

Thinking more on this issue, its not exactly an obvious result that development and deployment should be seperated. Part of the problem that the Dockerstack's is intended to solve is a non standardized development environment. The docker stacks still achieve this goal, if they still handle the packagement, and the build instructions necessary for building neuronunit itself, in fact Neuronunit should still really be installed, and then subsequently removed in the dev container only.

[rgerkin]

@russelljjarvis The Dockerfile at docker-stacks/neuronunit currently does two things:

• It downloads the latest dev branch from github to /home/jovyan and then does pip install -e on this to put it on the PYTHONPATH.
• It also puts /home/jovyan/work/neuronunit onto the PYTHONPATH at the very front. However, there is nothing there by default, so it is up to you to mount your current working copy of neuronunit from the host to that location. If you do so, i.e. with either the -v flag or simply by using the shell script I provided with the -dev flag, then your local working copy of neuronunit will be the one that gets imported inside the container. And you can edit it locally and have changes reflected normally inside the container.

This has worked for me. Can you describe the "fighting" you are doing that isn't resolved by this approach? Maybe I have overlooked something.

[russelljjarvis]

This problem only comes up on my purely linux machine, and it's entirely possible I just need to pull from dock stacks again. That machine has /opt/conda/lib/python3.5/site-packages/neuronunit in its path. Its entirely possible that this is something I have brought on myself.

I will double check my configuration, it could be the case that at some point I installed neuronunit in one of my own docker containers

Running the shell program with the -dev flag does not work for me at the moment, but I suspect that I may have broken the file when I edited it last.

[rgerkin]

@russelljjarvis One requirement of using the -dev flag is that you have a SCIDASH_HOME environment variable on your local machine, and that your working copies of both sciunit and neuronunit be located there, e.g. $SCIDASH_HOME/neuronunit.

[russelljjarvis]

Okay, as you imply setting SCIDASH_HOME with:

export SCIDASH_HOME="$HOME/git"

somewhere (for me in ~/.bashrc) fixes my problem. the BASH program bash shell [existin g_container_name] -dev is now runnable.