Question: How would I preserve ipython history between docker-compose runs with the local setup? (Answer is within)

[floer32]

• I'm submitting a ...
  • quick Q&A tip, I'll answer it myself then close the issue.

---

Question: How would I preserve ipython history between docker-compose runs with the local setup?

When using docker-compose for local development, how would you preserve the ipython history between different runs of shellplus?

Answer: Just two lines in your local.yml

Extending the excellent setup that comes with cookiecutter-django, and adding this little change to the local.yml, is not hard. Make sure you've read these docs first

The quick change, as a .diff

diff --git a/local.yml b/local.yml
index b587373..73684bf 100644
--- a/local.yml
+++ b/local.yml
@@ -3,6 +3,7 @@ version: '2'
 volumes:
#...
+  ipython_data_local: {}

 services:
   django:
#...
     volumes:
+      - ipython_data_local:/root/.ipython/profile_default   # persist ipython data, including ipython history
#...

Explained in more detail

Copying from my gist here

First do whatever you've been doing, to start your ipython shell inside of your docker-compose setup.
For example, I've got a project based on cookiecutter-django,
and this is how I was entering a shell for my project locally:

docker-compose run --rm django python manage.py shell_plus

So after doing that I checked where my ipython history might be.

$ docker-compose run --rm django python manage.py shell_plus
#...

In [1]: !ipython locate profile default
/home/someuser/.ipython/profile_default

Now that I have the path, I can use a volume to persist it using
the docker-compose YAML directives for this.

I can add this to volumes section of my docker-compose YAML file:

volumes:
    ipython_data_local: {}

Then in the section for the Python service:

services:
  django:
    volumes:
      - .:/app  # this was already here
      - ipython_data_local:/root/.ipython/profile_default   # persist ipython data, including ipython history
#.........................`

And that'll do it :-)

Disclaimer

BY THE WAY: you only get certain benefits of Docker or Docker-Compose if you keep local and production almost identical. That's still recommended. production.yaml should work locally, for example. Even so, a local.yaml that is very productive and efficient can be a good idea, especially when you have contributors who might have trouble maintaining their own stable environment. So that's the intended use case of this.

Please do not open shells in production using this trick. Please interact responsibly :)

[floer32]

Related: #1794