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