Here's what I ended up doing in case it's either useful for
others, or a really bad idea and serves as an anti-example.
0) For context, the working directory has roughly this setup
(after git submodule calls):
```
git-root
|-- main_project
|-- deps/
| |-- vibe-serialization
| |-- ... more here
|
|-- makefile
```
1) Add dependencies as git submodules, for example:
```bash
git submodule add https://github.com/vibe-d/vibe-serialization
deps/vibe-serialization
# more here
```
2) In the top level build file (makefile in my case) the
following happens:
```bash
dub add-local vibe-serialization 1.0.7
# More locals added here
cd main_project && dub --skip-registry=all build
dub remove-local vibe-serialization
# more locals removed here
```
3) On a regular basis:
```bash
rm -r $HOME/.dub
```
You never know what could be hiding in there.
A person can just `cd main_project && dub build` and standard
things will happen, i.e. dependencies will be downloaded from the
internet. However in a production setting `make` is run from the
top level and only the dependencies specified in the sub modules
are used.
This should work *unless* two builds are happening at the same
time in the same account since `add-local` and `remove-local` are
**user-wide** and affect an entire user's home directory at a
time. Not too bad if the user is a real person, *terrible* if
it's the account used by a build host.
It works, but I'm sure there's a better way.
