[gsoc] DUB - Ideas

[Nick Sabalausky (Abscissa)]

On 3/4/19 12:19 PM, Jacob Carlborg wrote:
> On 2019-03-04 06:32, Nick Sabalausky (Abscissa) wrote:
> 
>> Notice that not only is `dub.selections.json` included in version 
>> control, but I also have another file: 
>> `dub.selections.vibe-0.8.3.json`. That's because some compiler 
>> versions require vibe v0.7.x and NOT v0.8.x, but newer compilers 
>> require v0.8.x and up. So `dub.selections.json` is carefully set (by 
>> hand) to exactly my minimum dependency versions. And 
>> `dub.selections.vibe-0.8.3.json` is carefully set to the minimum 
>> versions required by the newer compilers.
> 
> Usually `dub.selections.json` should not be committed for libraries, 
> only for applications.

Well, its absolutely mandatory if you want your CI builds to be 
reproducible. (As they SHOULD be, unless you enjoy completely 
unnecessary potential problems.)

Although, come to think of it, I guess I could just rename it to 
`dub.selections.ci-default.json` and have my travis setup script 
automatically rename that to `dub.selections.json` if I haven't chosen 
any other alternative dub.selections for the current CI job.

But I'm not sure I see the harm in including `dub.selections.json`, 
though. If you're using the given project as a lib in your own project, 
dub doesn't actually do anything with the `dub.selections.json`s from 
the dependencies...or does it? 'Cause *that* would be bad...(Though I 
can't imagine *why* it would intentionally work that way.)

> With the latest version of Dub it's now possible to specify which 
> compiler is required [1]. That could potentially have solved your 
> problem.
 > [1] https://dlang.org/changelog/2.085.0.html#toolchain_requirements

Yea, just saw that myself. I'm definitely thrilled to see it added (for 
other reasons), I wish it had been added years ago, but I don't see how 
it would help the cases I mentioned above.

> I'm not sure if this means that Dub will try to pick an older 
> version of the dependency if the compiler requirement doesn't match.

Hmm, maybe, I hadn't thought of that. I certainly hope so. But in any 
case, the vide-d versions supported by mysql-native lack the 
"toolchainRequirements" directive (as they predate it), so it doesn't 
help mysql-native's existing cases here, at least not anytime in the 
near future. It also doesn't help with needing to test on the minimum
supported dependency versions.