On Sunday, 4 October 2020 at 14:08:24 UTC, Anonymouse wrote:
My project depends on the requests dub package, which has two
build configurations; one with an extra vibe-d dependency, one
without (default).
"configurations": [
{
"name": "std"
},
{
"name": "vibed",
"versions": ["vibeD"],
"dependencies": {
"vibe-d": ">=0.8.0"
}
}
],
I only ever use the default "std" configuration, but dub always
pulls the additional multiple vibe-d dependencies, regardless
of what I pick. Adding a subConfiguration restriction does not
seem to help.
$ dub upgrade
Upgrading project in /home/zorael/src/kameloso
Fetching vibe-core 1.10.2 (getting selected version)...
Fetching memutils 1.0.4 (getting selected version)...
Fetching taggedalgebraic 0.11.18 (getting selected version)...
Fetching vibe-d 0.9.2 (getting selected version)...
Fetching botan-math 1.0.3 (getting selected version)...
Fetching stdx-allocator 2.77.5 (getting selected version)...
Fetching botan 1.12.18 (getting selected version)...
Fetching diet-ng 1.7.4 (getting selected version)...
Fetching openssl 1.1.6+1.0.1g (getting selected version)...
Fetching eventcore 0.9.9 (getting selected version)...
Fetching mir-linux-kernel 1.0.1 (getting selected version)...
Fetching libasync 0.8.6 (getting selected version)...
Is there any way to stop this?
The reasoning is explained here:
https://github.com/dlang/dub/wiki/FAQ#why-are-dependencies-downloaded-that-belong-to-configurations-that-are-not-being-built
While these dependencies are downloaded, they will not be part of
your binary.
At the moment the only chance to avoid these additional
dependencies would be to split requests into 2 dub packages. The
core package which uses std, and an additional package which is
based on the core package and is using vibe-d.
Kind regards
Andre
