[gsoc] DUB - Ideas

[Nick Sabalausky (Abscissa)]

On 3/3/19 12:03 PM, Joseph Rushton Wakeling wrote:
> On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:
>> @community: what features do you miss the most from DUB?
> 
> (1) Support for library maintainers' test requirements
> 
> Specifically: when a library has dependencies of its own, one wants to 
> be sure the library stays compatible with the stated minimum supported 
> version, because changing that could be a breaking change for downstreams.
> 
> With this in mind it would be useful to have:
> 
>    * a command to downgrade all dependencies in dub.selections.json
>      to the minimum supported (including dependencies of dependencies)
> 
>    * a flag for build and test commands to request that the minimum
>      versions of all dependencies be used
> 
>    * a flag to specify the maximum kind of version change `dub upgrade`
>      can perform: patch, minor, or major.

Big "ditto" on this stuff. Althouth I'd change it to just "Support for 
library maintainers' requirements" in general.

I've already had to deal with that stuff you mention by hacking it all 
into my travis setup scripts and then have a custom test runner script 
invoke `dub test`.

For example, take a look at mysql-native's root dirctory:
https://github.com/mysql-d/mysql-native

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.

So then, in my travis setup script (ci_setup.d), I check for the envvar 
DUB_SELECT. If it exists, I overrwite `dub.selections.json` with 
`dub.selections.$(DUB_SELECT).json`:
https://github.com/mysql-d/mysql-native/blob/2f9d71ca026dc675d07bfb4dd20ce44e07c9aac5/ci_setup.d#L37

The travis setup script also checks for another envvar, DUB_UPGRADE. If 
it's true, then I run "dub upgrade".

So then, in my travis build matrix, I set up jobs both with and without 
DUB_SELECT/DUB_UPGRADE, as needed:

DUB_SELECT: 
https://github.com/mysql-d/mysql-native/blob/2f9d71ca026dc675d07bfb4dd20ce44e07c9aac5/.travis.yml#L15

DUB_UPGRADE: 
https://github.com/mysql-d/mysql-native/blob/2f9d71ca026dc675d07bfb4dd20ce44e07c9aac5/.travis.yml#L119

Resulting tests: https://travis-ci.org/mysql-d/mysql-native/builds/497662010

BUT WAIT, THERE'S MORE WORKAROUND! Notice that when DUB_UPGRADE *isn't 
set, I still run `dub upgrade`, but with the `--missing-only` flag:
https://github.com/mysql-d/mysql-native/blob/2f9d71ca026dc675d07bfb4dd20ce44e07c9aac5/ci_setup.d#L59

I needed to do that (which is an incredibly unintuitive way to pre-fetch 
all the dependencies without upgrading any), because the frequent dub 
server outages were causing jobs to be marked as "failed the tests" when 
really they were just "job error".

One thing I absolutely refuse to do is manage a library that demands all 
users always "upgrade all the things or STFU". I only believe in 
dropping support when it's necessary, not "because I can" or "because I 
know my users' needs better than they do and I say they don't need 
version latest-1". So, I need to deal with this stuff.

So, yea, some of this stuff *technically* *can* be done, but it would be 
REALLY nice if I didn't have to jump through all these hoops and hacks.

And yes, once again, all this ultimately comes down to DUB demanding to 
always be the center of the world.