This is why I don't use D.

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Sep 7 15:24:13 UTC 2018


On Friday, September 7, 2018 8:36:11 AM MDT 0xEAB via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 20:08:08 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via
> >
> > Digitalmars-d wrote:
> >> Ah, but would you actually pay for such a service to be set up?
> >>
> >> https://forum.dlang.org/thread/acxedxzzesxkyomrsmjo@forum.dlang.org
> >>
> >> It's all well and good to hope for such services, but they're
> >> unlikely to happen unless paid for.
> >
> > That's actually something that I could see happening without
> > anyone being paid to do it, but it's much more likely to get
> > done in a timely manner if someone is paid to do it, and it's
> > arguably critical enough for the dub ecosystem that it's
> > something that the Foundation should pay someone to do.
> >
> > - Jonathan M Davis
>
> The software itself is pretty simple (besides it has to deal with
> some DUB bugs). It would just need someone to run it. If running
> it every DMD release is sufficient and if it doesn't need to be
> automated, it won't be such a big deal anymore.
>
> By the way, I'm currently playing around testing DUB packages
> with my prototype.

I don't see how such a system could work very well if it's not automated.
Simply doing it with every release of dmd means that newer packages won't be
tested, and it would force someone to take the time to run stuff every dmd
release, which they may or may not have time to do. IMHO, it really only
makes sense to set up something automated.

I would expect that any time code.dlang.org detected that a package had a
new version (or a package was added), the new versions would be tested.

What's somewhat more of an open question is how new compiler releases should
be handled. Aside from the issue that _every_ package then potentially needs
to be tested (which could take a while), there's the issue of which versions
to test. Testing every release of a package would be overkill, but simply
testing the latest isn't necessarily enough.

Also, there's the question of what it even means to test each package to
verify that it's working. Does that mean running the unit tests? Not all
projects run them the same way, and it could be pretty expensive to run the
tests for all packages on code.dlang.org. And of course, that assumes that
the package even has any unit tests to begin with. So, should testing the
package just mean that dub build works? That will catch the really basic
problems, but it won't usually catch problems in templates and could easily
miss other types of problems - though maybe it's enough. Regardless, it's
going to need to be made clear what it means that code.dlang.org claims that
a package works with a particular version of the compiler.

All in all, while this seems like a great idea, the more I think about it,
the more it seems like it could get pretty thorny when sorting out all of
the details.

- Jonathan M Davis





More information about the Digitalmars-d mailing list