This is why I don't use D.

[Nick Sabalausky (Abscissa)]

On 09/05/2018 05:49 PM, H. S. Teoh wrote:
> On Wed, Sep 05, 2018 at 04:40:19PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> [...]
>> What we need is for DUB to quit pretending the compiler (and DUB
>> itself, for that matter) isn't a dependency just like any other. I
>> pointed this out years ago over at DUB's GitHub project, but pretty
>> much just got silence.
> 
> Yeah, to truly capture dependencies properly, you need to specify the
> dub version and the compiler version(s).  And dub needs to treat this
> just like any other dependency.
> 
> The problem with compiler versions, though, is that while you can
> specify a minimum compiler version (e.g., if you use a feature that's
> not implemented in earlier versions), you can't reasonably specify a
> maximum compiler version, because you can't predict when your code will
> stop compiling due to future changes in the language / compiler and/or
> future regressions.  For the latter, you still need a CI infrastructure
> to periodically test your code against the latest compiler toolchain to
> determine whether or not it still compiles.
> 
That's something else I've been thinking for awhile would be really good 
to integrate into a package manager: CI results. I'm not aware of any 
package manager that does it. (Though my worldview can be a bit small, 
so who knows?)

In the olden days of D, for my libs and projects and such, I used to 
maintain a note in my source, readme, etc about "This project has been 
tested to compile with DMD vBlah, blah, blah". And changes would be 
noted in the changelog.

Of course that was horrible, so now that there's CI, all my projects 
define "supported compiler versions" as "Whatever is listed in 
.travis.yml/appveyor.yml". And I try to be explicit about that in the 
readme, and provide a link to the file.

Personally, I think that's a really good way to go. However, for awhile 
now, I've been starting to think: "Wouldn't it be awesome to have a 
packager manager that AUTOMATICALLY picks up compatibility information 
directly from each project's CI results for each tagged release?"

I think that would be freaking sweet.

It would also be nice to have a simple, built-in way to test against 
multiple dependency versions. Right now, I have some projects that kinda 
hack around that by using a custom buildscript that checks an envvar I 
can set in .travis.yml for an alternate dub.selections.json to be used 
in-place of dub.selections.json (by copying overtop the default one). I 
mainly use that for compiler versions that require alternate versions of 
my project's dependencies (usually vibe.d). But it can also be used to 
test on a range of dependencies. So far, I like to test on both "oldest 
supported dep versions" and "latest available". Ideally, I'd like to 
expand that though, although it is a tradeoff between basic rigor vs not 
soaking up too much of the CI's free resources.

It's nice, but problem is, all that could be handled much better, given 
proper support from a package manager. But the biggest thing that would 
help here is still just proper orthogonal handling of dependencies (ie, 
not treating compiler and package manager as the dependencies they 
really are).

(Weird...I just realized, I think my spellchecker is set to a UK dict 
instead of a US one. Not sure if it's Thunderbird or my whole system 
(Manjaro), or what to do about it...Ugh, more futzing ahead...)