Brian 1 depends on Python 2.x and other outdated dependencies, so running it on modern systems has become difficult. To make it more convenient to reproduce old results obtained with Brian 1, we now provide a Docker image 
that you can use to run existing Brian 1 code. It is based on a Debian Linux image, and provides Brian 1.4.3, as packaged by the NeuroDebian team.
The image is hosted on the Docker hub. To use it, you either need to have docker or podman installed – if using podman, replace the docker commands below by podman.
Running a graphical interface within the docker container can be complicated, and the details how to make it work depend on the host operating system. We therefore recommend to instead either 1) only use the container image to generate and save the simulation results to disk, and then to create the plots on the host system, or 2) to use the container image to plot files to disk by adding plt.savefig(...) to the script. The container already sets the matplotlib backend to Agg by default (by setting the environment variable MPLBACKEND), necessary to avoid errors when no graphical interface is available.
To download the image and to rename it to brian1 (for convenience only, the commands below would also work directly with the full name), use:
docker pull docker.io/briansimulator/brian1.4.3
docker tag briansimulator/brian1.4.3 brian1
The following command runs myscript.py with the container image providing Brian 1 and its dependencies, mapping the current directory to the working directory in the container (this means, the script has access to all files in the current directory and its subdirectories, and can also write files there):
docker run -v "$(pwd):/workdir" brian1 python myscript.py
For Windows users using the Command Prompt (cmd.exe) instead of the Powershell, the following command will do the same thing:
docker run -v %cd%:/workdir brian1 python myscript.py
To run an interactive ipython prompt, use:
docker run -it -v "$(pwd):/workdir" brian1 ipython
Depending on your operating system, files written by the container might be owned by the user “root”, which can lead to problems later (e.g. you cannot rename/move/delete/overwrite the file on your home system without administrator rights). On Unix-based systems, you can prevent this issue by running scripts with the same user id as the host user:
docker run -u $(id -u):$(id -g) -v "$(pwd):/workdir" brian1 python myscript.py
Please let us know if you run into any issues!
, so not sure whether this is really a problem in practice… But would be great if you could try it out. Basically running any Brian 1 example, e.g. 