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

[Neia Neutuladh]

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`.

> 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?

> 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.