This is why I don't use D.

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Sep 6 16:50:32 UTC 2018


On Thu, Sep 06, 2018 at 04:32:09PM +0000, Everlast via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter wrote:
[...]
> > What annoys people is not that there are broken packages in the
> > list, but that there is no way to know beforehand if one is choosing
> > a reliable package or a hobby experiment gone wrong. This
> > uncertainty is grating imo.
> 
> The problem is that google isn't going to help. Most people find
> packages by searching google in some way and then follow that rabbit
> hole. It would be impossible to know then until it's too late.
> 
> But things such as your suggestions can mitigate the problem. Dub, for
> example, could have a list of reliable packages built in(or could have
> a master list) that can automatically inform the user about these
> issues...  rather than the user having to look up on a web page.
[...]

Again, this strongly suggests the idea I've mentioned a few times now:
*all* packages on code.dlang.org needs to be run through a CI tester,
and success/failure to compile should be reported back to dlang.org
somehow.  Then in the search results and in the package's home page,
there should be a prominently-displayed notice of which compiler
versions work / don't work with the package.

This gives users the information they need to make the right decision
(e.g., the last known compiler that compiles this package is 2.060, so
don't bother, move on.).

And this *must* be automated, because nobody has the time or energy to
manually test every package against every known compiler release and
manually update code.dlang.org.  And doing it manually tends to quickly
get out of date, not to mention the chance of human error.


T

-- 
Ignorance is bliss... until you suffer the consequences!


More information about the Digitalmars-d mailing list