On Monday, 6 January 2025 at 03:04:40 UTC, Chris Piker wrote:
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.
There is nothing wrong with your example, having two ways to
build artifacts maybe confusing but this is just fine, except
maybe that you should clearly state your intentions and name
scripts/makefile accordingly (e.g. build_prod.sh/build_dev.sh or
something, meaning that is it only going to work in specific
environment because this is a part of specific procedure)
There is a problem with `dub add-local` though, it is only useful
for developer on that same machine while tinkering with
problematic packages. But this is an extra step that is easily
can be forgotten leading to confusion.
I think it can be avoided entirely by simply setting explicit
paths to dependencies in `dub.selections.json` (not suitable for
library projects as you can't freeze version for your users), not
sure if it will actually work with relative paths but I guess it
should.
__dub.selection.json__:
```json
{
"fileVersion": 1,
"versions": {
"godot-dlang": {"path":"C:/godot/bin/godot-dlang"},
"intel-intrinsics": "1.11.18",
"pyd": "~master"
}
}
```
