It's DUB's "optional": true broken ?

Zardoz luis.panadero at gmail.com
Sun Mar 28 19:53:53 UTC 2021


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.


More information about the Digitalmars-d-learn mailing list