• Zardoz (67/67) Mar 28 2021 So, we get this dub.json :
• Zardoz (55/124) Mar 28 2021 I think that I can self-answer me. Looks that this related to
• Andre Pany (10/31) Mar 29 2021 Assumption: dshould has 2 configurations. In first configuration,

Zardoz <luis.panadero gmail.com> writes:

So, we get this dub.json :

{
   "name": "example",
   "configurations": [
     {
       "name": "example",
       "targetType": "library"
     },
     {
       "name": "unittest",
       "targetType": "library",
       "importPaths": ["source", "tests"],
       "sourcePaths": ["source", "tests"],
       "dependencies": {
         "silly": "~>1.0.2",
         "dshould": "~>1.4.3"
       }
     }
   ]
}

Where "dshould have a dependency to unit-threaded marked as 
"optional", and not have any "default" set to true. DUB 
documentation says that the proyect not must pick the optional 
dependency if I not edit manualy dub.selections.json to pick 
unit-threaded.

Well.. DUB ignores and picks unit-threaded as I can show here :

$ dub build
Performing "debug" build using /usr/bin/dmd for x86_64.
sybok ~master: building configuration "sybok"...
$ dub test
Generating test runner configuration 'sybok-test-unittest' for 
'unittest' (library).
Performing "unittest" build using /usr/bin/dmd for x86_64.
prettyprint 1.0.7: building configuration "library"...
unit-threaded:from 1.0.14: building configuration "library"...
unit-threaded:exception 1.0.14: building configuration 
"library"...
unit-threaded:assertions 1.0.14: building configuration 
"library"...
unit-threaded:integration 1.0.14: building configuration 
"library"...
unit-threaded:mocks 1.0.14: building configuration "library"...
unit-threaded:property 1.0.14: building configuration "default"...
unit-threaded:runner 1.0.14: building configuration "library"...
unit-threaded 1.0.14: building configuration "library"...
dshould 1.4.3: building configuration "library"...
sybok ~master: building configuration "sybok-test-unittest"...
Linking...
To force a rebuild of up-to-date targets, run again with --force.
Running ./sybok-test-unittest
  ✓ sybok_spec Sybock test

Summary: 1 passed, 0 failed in 0 ms

And dub.selections.json show this :

{
         "fileVersion": 1,
         "versions": {
                 "dshould": "1.4.3",
                 "prettyprint": "1.0.7",
                 "silly": "1.0.2",
                 "unit-threaded": "1.0.14"
         }
}

Plus, If edit dub.selections.json to remove unit-threaded , every 
time that I launch dub test, overwrites dub.selections.json and 
picks again unit-threaded.

 From my point of view, or documentation it's wrong, or there it's 
something really broken about this functionality.

Zardoz <luis.panadero gmail.com> writes:

On Sunday, 28 March 2021 at 15:52:43 UTC, Zardoz wrote:
 So, we get this dub.json :

 {
   "name": "example",
   "configurations": [
     {
       "name": "example",
       "targetType": "library"
     },
     {
       "name": "unittest",
       "targetType": "library",
       "importPaths": ["source", "tests"],
       "sourcePaths": ["source", "tests"],
       "dependencies": {
         "silly": "~>1.0.2",
         "dshould": "~>1.4.3"
       }
     }
   ]
 }

 Where "dshould have a dependency to unit-threaded marked as 
 "optional", and not have any "default" set to true. DUB 
 documentation says that the proyect not must pick the optional 
 dependency if I not edit manualy dub.selections.json to pick 
 unit-threaded.

 Well.. DUB ignores and picks unit-threaded as I can show here :

 $ dub build
 Performing "debug" build using /usr/bin/dmd for x86_64.
 sybok ~master: building configuration "sybok"...
 $ dub test
 Generating test runner configuration 'sybok-test-unittest' for 
 'unittest' (library).
 Performing "unittest" build using /usr/bin/dmd for x86_64.
 prettyprint 1.0.7: building configuration "library"...
 unit-threaded:from 1.0.14: building configuration "library"...
 unit-threaded:exception 1.0.14: building configuration 
 "library"...
 unit-threaded:assertions 1.0.14: building configuration 
 "library"...
 unit-threaded:integration 1.0.14: building configuration 
 "library"...
 unit-threaded:mocks 1.0.14: building configuration "library"...
 unit-threaded:property 1.0.14: building configuration 
 "default"...
 unit-threaded:runner 1.0.14: building configuration "library"...
 unit-threaded 1.0.14: building configuration "library"...
 dshould 1.4.3: building configuration "library"...
 sybok ~master: building configuration "sybok-test-unittest"...
 Linking...
 To force a rebuild of up-to-date targets, run again with 
 --force.
 Running ./sybok-test-unittest
  ✓ sybok_spec Sybock test

 Summary: 1 passed, 0 failed in 0 ms

 And dub.selections.json show this :

 {
         "fileVersion": 1,
         "versions": {
                 "dshould": "1.4.3",
                 "prettyprint": "1.0.7",
                 "silly": "1.0.2",
                 "unit-threaded": "1.0.14"
         }
 }

 Plus, If edit dub.selections.json to remove unit-threaded , 
 every time that I launch dub test, overwrites 
 dub.selections.json and picks again unit-threaded.

 From my point of view, or documentation it's wrong, or there 
 it's something really broken about this functionality.

I think that I can self-answer me. Looks that this related to 
this : https://github.com/dlang/dub/issues/1706

DUB it's downloading unit-threaded, but not linking against it or 
using it for run the unit tests. It's more evident if I invert 
the situation :

If I have this dub.json

{
   "name": "example",
   "configurations": [
     {
       "name": "example",
       "targetType": "library"
     },
     {
       "name": "unittest",
       "targetType": "executable",
-      "preBuildCommands": ["$DUB run --compiler=$$DC 
unit-threaded -c gen_ut_main -- -f bin/ut.d -d $DUB"],
-      "mainSourceFile": "bin/ut.d",
       "importPaths": ["source", "tests"],
       "sourcePaths": ["source", "tests"],
       "dependencies": {
         "unit-threaded": "~>1.0.14",
         "pijamas": "~develop"
       }
     }
   ]
}

Uses unit-threaded runner, as is expected.

If I use this dub.json :

{
   "name": "example",
   "configurations": [
     {
       "name": "v",
       "targetType": "library"
     },
     {
       "name": "unittest",
       "importPaths": ["source", "tests"],
       "sourcePaths": ["source", "tests"],
       "dependencies": {
         "unit-threaded": "~>1.0.14",
         "pijamas": "~develop"
       }
     }
   ]
}

Uses the default unit tests runner and not Silly runner that it's 
leaked from pijamas (Pijamas uses Silly on a "unittest" config, 
but DUB downloads Silly, even when this project it's using it.

This behavior should be on DUB's documentation. It's pretty 
confusing seeing that DUB it's downloading libraries that would 
never use, and gives the false impression that it's using it.

Andre Pany <andre s-e-a-p.de> writes:

On Sunday, 28 March 2021 at 15:52:43 UTC, Zardoz wrote:
 So, we get this dub.json :

 {
   "name": "example",
   "configurations": [
     {
       "name": "example",
       "targetType": "library"
     },
     {
       "name": "unittest",
       "targetType": "library",
       "importPaths": ["source", "tests"],
       "sourcePaths": ["source", "tests"],
       "dependencies": {
         "silly": "~>1.0.2",
         "dshould": "~>1.4.3"
       }
     }
   ]
 }

 [...]

Assumption: dshould has 2 configurations. In first configuration, 
unit-threaded is marked as optional in second it isn't. Dub 
therefore downloads it per rule (all configurations are 
considered, also the not used).

The author could mark it in all configurations as optional or, 
use sub packages, which is another way to have optional 
dependencies.

Kind regards
Andre