# Common Code for Python Stuff

### For docker builds:

Docker kinda sucks at providing a way to use shared code in a monorepo
like this so here's the workaround we use:

In the project folder create a build.sh script that does the following

```bash

#! /bin/bash

mkdir -p .dbuild
cp -r ../pycommon/pycommon .dbuild/
cp -r ../pycommon/requirements.txt .dbuild/requirements-pycommon.txt
docker build -t [whatever image name] .

```

The Dockerfile should include

```dockerfile

COPY .dbuild/requirements-pycommon.txt .
RUN pip install -r requirements-pycommon.txt

ADD .dbuild/pycommon ./

```

The top level .gitignore already excludes .dbuild folders so it should not get commited.

### For local python'ing (in a venv)

If you are doing stuff not in a docker image, the pycommon can be symlinked.

```sh
> ln -s ../pycommon/pycommon
```

Which should allow imports `from pycommon` to work. (provided `'.'` is on the
PYTHON_PATH which it generally is in scripts and ipython).

Note that even though the docker build can't handle symlinks, mounting voolumes is no problem
so this means when messing aound locally you can do:

```sh
> docker run -v `pwd`/pycommon [whatever image name]
```

And the host pycommon folder will be mounted correctly in the image.

We don't take a wheel or pip approach to pycommon. We could in the future if versioning
becomes an issue, but hopefully it never will. A single githash should represent the always
runnable source of truth. This method above favours pycommon always being 'up to date'
and hence changes should be backwards compatible, or callers updated in the same commit.

There are other suggestions for using docker with shared code, but all involve using the root as the docker context.
This would end up with really large docker contexts (since you can't specify alternative
docker ignore files), and Dockerfiles would have to expect to be ran from ..

I prefer to keep the docker build within the project, and hence the project root (one
level down from the repo root). Also the symlink approach within the project keeps IDEs happy, and encourages editing of the shared library, whihch is a good thing, it
shouldn't atrophy.