Configuration-only dependencies should not take part in version resolution

[atilaneves]

Currently, if package foo has:

dependency "bar" version="*"
configuration "unittest" {
     dependency "unit-threaded" version="==0.7.1"

And package bar has:

configuration "unittest" {
    dependency "unit-threaded" version="==0.7.2"

Then foo will fail to build due to version mismatches, even though bar is using the default configuration, not unittest.

The fix would be to only consider bar dependencies applicable to the configuration actually being built (usually default but could be something else if subConfiguration is used).

[BenjaminSchaaf]

A successful workaround for this issue is to use a sub-project for your tests and have the test dependencies only in that sub-project.

[Geod24]

@RUSshy : Any fix for this would be appreciated (and pulled), it's just that no one got to it yet. It's not an easy problem to solve. See #1706 which is a duplicate of this.

[atilaneves]

It's especially not easy to fix since the main issue is that dub.selections.json tries to be one-size-fits-all, which it can't be. The list of dependencies and even maybe their exact versions depend on the configuration, so version 2 of the file format should be a JSON object with an entry for each configuration. The current architecture doesn't work, making a fix a lot harder.

[s-ludwig]

Honestly, this is an oversimplification of the matter. This is not just about the file format or how the dependency resolution is set up. Having a set of dependencies/versions per configuration will make the whole feature useless or impractical in many cases. You'd have to maintain/upgrade dependencies for all configurations and all supported platforms separately, which may work with a lot of automation and a proper CI infrastructure, but otherwise doesn't seem like a sane approach.

What could be solved without much issues would be the download problematic, by making package downloads lazier where possible.

I don't have a solution at hand for the original issue with mutually exclusive version ranges, other than supporting to build against multiple versions of the same package at once (I just remember there was a SAoC project idea for that or something similar). I don't like that idea for multiple reasons, though. Maybe we can find some middleground between the current approach and the free one-selection-set-per-configuration-and-platform combination...