On Sunday, 3 March 2019 at 17:03:20 UTC, Joseph Rushton Wakeling wrote:
> Example: if one runs `dub test --build=release` then intuitively one would expect (unit)tests to be run with release flags and optimizations enabled. In fact no unittests are run, because `--build=release` mandates a specific set of D flags that does not include `-unittest`.

As a work-around you can use buildTypes today: https://p0nce.github.io/d-idioms/#Unittests-with-optimizations-:-the-Final-Frontier

I think it would be a good idea to have this in vanilla DUB.

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.

On 3/3/19 7:01 AM, Guillaume Piolat wrote:
> 
> Well, to me the ONLY reasons DUB use SDLang and cargo use TOML is obviously... to make things as different as possible! It's just trying to be different for being different's sake.
> 
> Sociology explains this way more than any technical merit, we are prone to this in the D community because well it's an alternative language, it selects for people who likes alternatives.
> 
> This is the elephant in the room, why else would we argue (with so much passion) the technical merit of 20-lines recipe files?

1. Because I've already wasted enough of my life suffering shitty tools.

2. Because no amount of insignificance will ever turn an inferior choice into a superior one.

3. Because any coup needs to start somewhere.

As for the elephant, it's only a photo on the wall...

> And TOML is really tragic, I don't know if you have tried using it, I have and reverted to XML.

I haven't. This thread is the first I've heard of it. That's unfortunate to hear as it *seems* very nice at a glance. What issues did you have?

On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:
> @community: what features do you miss the most from DUB?

Nested subpackages:
https://github.com/dlang/dub/issues/843

On Sunday, 3 March 2019 at 15:59:44 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 3 March 2019 at 13:43:15 UTC, Seb wrote:
>> On Sunday, 3 March 2019 at 13:24:21 UTC, Joseph Rushton Wakeling wrote:
>>> One can already just add a git submodule and point the dub dependency declaration at the resulting directory.
>>
>> Dub doesn't support git submodules (because it downloads the Zip archive from GitHub/GitLab).
>
> I think we may be talking at cross-purposes.  Here's what I was suggesting w.r.t. using git repos as a source for dub dependencies:
>
> (1) add a submodule to your current project (let's use mir-glas as an example):
>     git submodule add --name mir-glas https://github.com/libmir/mir-glas.git mir-glas
>
> (2) add a dependency to dub.json pointing at the submodule directory:
>
>         "dependencies": {
>             "mir-glas": { "path": "./mir-glas" }
>         }
>
> This is only really needed though if one wants to create dependencies on projects that are not public DUB packages.  I think this ought to also support nested submodules, though I have not tried it.

This doesn't work. Worse, it actually does work if you test adding this dub package (the one that has mir-glas as a dependency) locally by using `path="/path/to/thing/needing/mir-glass"`. Then you tag a new version, try using a version dependency and... oops. Check out all the v0.2.x releases for autowrap here:

https://github.com/kaleidicassociates/autowrap/releases

Notice how they're all from two different days. That was me trying to make pyd a dependency as a git submodule. I have to give up and go up to v0.3.0 since none of those tags work.

On Monday, 4 March 2019 at 06:27:33 UTC, Nick Sabalausky (Abscissa) wrote:

> I haven't. This thread is the first I've heard of it. That's unfortunate to hear as it *seems* very nice at a glance. What issues did you have?


TOML make difficult for humans to write "Array of Tables"
https://github.com/toml-lang/toml

because it's where the flat idea break down.
Array of Tables of Array of Tables would be increasingly unworkable, whereas in JSON nesting happens normally.

On Monday, 4 March 2019 at 10:19:29 UTC, Atila Neves wrote:
> This doesn't work.

Exactly which bits of it?  I have actual projects that use git submodules to provide some dependencies for dub.  There are no nested submodules, though.

A constraint is that I'm tied to a _specific_ version of the dependency (determined by what commit or tag the git submodule checks out), but that's not actually a problem for the use-case (generally for production code I find it better to have precise control over dependency versions).

On Monday, 4 March 2019 at 13:12:09 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 4 March 2019 at 10:19:29 UTC, Atila Neves wrote:
>> This doesn't work.
>
> Exactly which bits of it?  I have actual projects that use git submodules to provide some dependencies for dub.  There are no nested submodules, though.
>
> A constraint is that I'm tied to a _specific_ version of the dependency (determined by what commit or tag the git submodule checks out), but that's not actually a problem for the use-case (generally for production code I find it better to have precise control over dependency versions).

Have you published any of these projects on the dub registry?
It wouldn't work for any potential users as dub wouldn't download the git submodules for you.

On Monday, 4 March 2019 at 13:26:43 UTC, Seb wrote:
> Have you published any of these projects on the dub registry?
> It wouldn't work for any potential users as dub wouldn't download the git submodules for you.

No, but that's the point: it's a way of integrating _private_ internal projects into DUB.  I wouldn't use it for public DUB packages, because what's the point?

The question is why you want a public DUB package to rely on submodules for parts of its code.  What's the use-case?  You still haven't described it.

On Monday, 4 March 2019 at 13:52:03 UTC, Joseph Rushton Wakeling wrote:
>
> The question is why you want a public DUB package to rely on submodules for parts of its code.  What's the use-case?  You still haven't described it.

You fix a bug in let's say Vibe.d (or any other library for that matter). You don't want to wait 6 months until your bug fix gets merged and released (if ever). I have run into this many many times.
In some cases I had to result to registering a duplicate repo on the registry as there was a breaking change in DMD and I (and the users of a depending library) wanted to continue using it.
Note that this shortcoming of dub was also the main reason why Dlang Community has been created.