Dub project has both .sdl and .json files. Is this normal or did I do something wrong?

[Bastiaan Veelo]

On Saturday, 4 August 2018 at 17:53:45 UTC, Neia Neutuladh wrote:
> On Friday, 3 August 2018 at 19:41:32 UTC, Bastiaan Veelo wrote:
>> But if you commit it, and a compiler deprecation causes a 
>> dependency in that pinned version to fail to compile, then 
>> your app won't compile either, even though your code itself 
>> does not suffer from the deprecation and even though a newer 
>> release of the dependency is available that solves the 
>> deprecations. This means that, if your app is on 
>> code.dlang.org, people won't be able to dub fetch && dub run.
>
> This is also true if the dependency gets a major version bump 
> and then gets updated for a breaking compiler change.
>
> If the dependency range is broad enough, you can `dub upgrade 
> && dub run`.

You mean the dependency range in dub.selections.json of an app on 
code.dlang.org? I would be in favour of it being a range, but I 
think that is unusual. Usually people just commit the generated 
file unedited, which seems to always be pinned to the patch level?

Anyway, dub documentation could be a lot more verbose on 
dub.selections.json :-)

>> What advantages does committing dub.selections.json have that 
>> outweigh this disadvantage?
>
> Dependencies don't always follow semantic versioning. For 
> instance, a binding for a C library that is actively developed 
> might reasonably follow the bound library's versioning. Or the 
> maintainer might make a mistake and commit a breaking change 
> without bumping to a new major version.
>
> This is why my top-level projects these days have specific 
> versions of dependencies rather than the more commonly used 
> ranges. I'm only going to test against those specific versions, 
> so why should I claim that my application can use future 
> versions?

I know that failing to build is better than potential erroneous 
execution, so I understand the rationale. It’s just that I get 
build failures after updating to the newest compiler often enough 
that it's frustrating. Build failures in tools that I use in my 
build that is, like dfmt, ddox, scod.

>> It would be OK if dub.selections.json would also pin the 
>> compiler version and there were a standard way to select that 
>> version (like dvm, but without its shortcomings).
>
> That would be good. If I were less lazy, I could add that to 
> dub. It already manages packages; the compiler is just a 
> slightly different dependency.

Apart from solving this problem, there are other advantages:
1. It would make it possible to check out an older version of 
your software and compile it without problems, and be sure that 
it results in the same binary as when that version was committed.
2. You can easily work with different compilers in different 
branches. Like using ldc in the release branch of your CI and dmd 
in your feature branch, or work on porting to a different 
compiler outside the master branch.

But since dub is distributed with the compiler, handling the 
compiler as a dependency might not be straightforward. How would 
you prevent getting trapped in an old version when dub downgrades 
itself? Which of the installed dub versions du you use to do dub 
upgrade? How would dub appear in dub.selections.json?

If you have ideas on this, I am genuinely interested.

-Bastiaan