On 09/07/2018 10:29 AM, 0xEAB wrote:
> On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky (Abscissa) wrote:
>> 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 result
> 
> How many projects do use CI, though? Especially how many of those that actually suffer from not being actively maintained?
> How many project maintainers are interested in playing around with different compiler versions on their CI?  Even if they are, in the end they will just remove old compilers as soon as building with them fails in order to get positive CI results...
> 

Those are all valid problems, but they're all equally problematic regardless of whether or not a package manager makes use of the CI data available.

But at least with a CI-aware pack manager, the package manager can at least avoid selecting a dependency combination that CI testing has already shown doesn't work.

Plus, if not enough projects use CI, than any additional incentive to nudge them into using it is only a good thing.

On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:
> There are ways around this:

Take a step back and consider what you're asking for.

You are asking for dub to become github. A very cruddy version of github. One in which everyone can submit changes to every repository. With a forum and a voting mechanism where anyone can vote. Where each person applies a complex set of rules to determine whether a given change should be applied to their local copy.

You expect this to improve reliability, when you're making it less likely that anyone else has seen the codebase that any particular person is using.

The security fixes you've suggested are defeated just by registering a few extra accounts, and the "does not escape" thing uses a term that I'm moderately sure you came up with.

You don't seem to understand the difference between trusting a specific person in charge of a repository, and trusting everyone in the world (or at least everyone who can make a dozen fake accounts and upvote their own patches).

You also haven't considered social options for dealing with the problem. See https://github.com/dlang-community/discussions for the organization we have that deals with this problem already.

On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:
> On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh wrote:
>> [...]
>
> There are ways around this:
>
> [...]

Is there any other language that does any of this? I don't think any language does all of it, so do you plan to wait a couple decades for any language to do it before you start programming?

Some of these are worthwile suggestions, but nobody's doing them yet. I suggest you start implementing them somewhere- maybe here, dub is an OSS project: https://github.com/dlang/dub - rather than lecturing others about how it's all so obvious. That way, you can actually get some work done before the cows come home. ;)

On Fri, 07 Sep 2018 09:35:29 -0700, H. S. Teoh wrote:

> ([*] I was going to suggest including dmd-nightly as well, but that poses the problem of load: running it every night will cause a lot of CI churn, which also generates a lot of mostly-useless information -- no one will care about which of 50 dmd git revisions failed / succeeded to compile a package, just whether the *latest* dmd-nightly works.  So perhaps an update once a week or once a month in between releases will be enough.  But dmd-nightly is an optional extra that can be skipped for now.  The important baseline is the current official releases of gdc / ldc / dmd.)

The beta might be better than dmd-nightly, as they would avoid the churn and still provide maintainers with time to react to problems with the upcoming release before the release is out.

On Saturday, 8 September 2018 at 11:24:50 UTC, rjframe wrote:
> The beta might be better than dmd-nightly, as they would avoid the churn and still provide maintainers with time to react to problems with the upcoming release before the release is out.

Betas are often outdated and contain problems that are already fixed in the released version. For example right now if you test something with dmd beta you test 2.082-beta.2 but 2.082.0 is already released. That sounds  crazy when you thing more about that.

On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky (Abscissa) wrote:
> 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.

We have something similar with dpldocs which builds docs lazily, and is now linked from code.dlang.org

It's a matter of extending it with downloading toolchain and building.

I can't speak for anyone else but it looks to me as a realistic way to have it.
You can also donate to Adam for http://dpldocs.info/, it has interesting things like cross-package search (search ALL of code.dlang.org at once)

On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
> 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

How would this work for packages that cannot be built by DMD? Or that have no CI infrastructure but are maintained? *cough* DCompute *cough*

On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis wrote:
> Honestly, I wouldn't rely on anything beyond dub build working in a consistent manner across projects. As far as I can tell, you can't actually do anything properly custom with dub test, and I'm inclined to think that how it approaches things is outright wrong.

For Dcompute I define a unittest configuration that has a main that runs tests, and the (default) library configuration excludes source files in the test directory. It seems to work fine. Admittedly it is a little different to you usual package, and there are no test specific symbols and no unit tests, and I haven't tested anything that has dcompute as a dependancy.

Are you suggesting this will break users of Dcompute that run dub test in their code? If so that truly does suck, because regular unittests will not cut the mustard.

On Saturday, September 8, 2018 7:44:09 AM MDT Nicholas Wilson via Digitalmars-d wrote:
> On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
>
> wrote:
> > Honestly, I wouldn't rely on anything beyond dub build working in a consistent manner across projects. As far as I can tell, you can't actually do anything properly custom with dub test, and I'm inclined to think that how it approaches things is outright wrong.
>
> For Dcompute I define a unittest configuration that has a main that runs tests, and the (default) library configuration excludes source files in the test directory. It seems to work fine. Admittedly it is a little different to you usual package, and there are no test specific symbols and no unit tests, and I haven't tested anything that has dcompute as a dependancy.
>
> Are you suggesting this will break users of Dcompute that run dub test in their code? If so that truly does suck, because regular unittests will not cut the mustard.

Okay. It's been several months since I dug into this, so hopefully I have the details straight.

Unless no one using dcompute uses dub test on their own projects, you probably don't have the worst part of this problem, because if you did, they'd be complaining about linker errors.

Honestly, unittest blocks in general are somewhat broken, but what really doesn't work correctly is code that's versioned for unit tests. e.g. if you've declared some types or functions to use specifically in your unit tests and which have no business being in the actual library (e.g. dxml has dxml/internal.d which includes stuff specifically to help the unit tests and is not part of the public API). The core problem is caused by the language, but the way dub handles things negates the workarounds for the problem.

When you import a module that includes unittest blocks, and you're compiling your module with -unittest, the version identifier unittest is defined when importing the module, meaning that all unittest blocks are processed, and everything inside a version(unittest) block is considered to be part of the module. With regards to the unittest blocks themselves, this is nothing but negative. It means that they have to compile regardless of whether everything they use is available to the module importing them, and it's a pointless waste of compiler resources. This is even worse when a unittest block is inside a template, because than anyone using that template then also gets the unittest blocks compiled into their code (once for each instantation of the template), meaning that the unittest blocks in the libraries you use can actually be compiled into your program and get run when you run your own unit tests. IMHO, when importing a module, unittest blocks should be treated as version(none) rather than version(unittest), but that's not currently the case.

The less straightforward problem is the helpers that are compiled with version(unittest). We can't treat everything that's version(unittest) as version(none) when importing, because that would make it impossible to share unit test helpers between modules. The cleanest way to deal with those is therefore to put them in a separate module that gets imported locally by the unittest blocks. That way, you don't accidentally mark anything in the module with the unittest blocks as version(unittest), and it allows you to hide the symbols from any modules that import your module. However, because the unittest blocks themselves are still processed when importing, it doesn't actually work to hide the symbols being imported like it should. The compiler still processes them when it imports the module. This causes problems when the modules being imported weren't actually compiled into the library that you're linking against (since normally, libraries aren't compiled with -unittest) - hence the linker errors. If you use unit test helpers that are version(unittest) in a library, you risk linker errors in any project that imports that library. Not marking them with version(unittest) can fix that problem, but it then pollutes projects using the library.

While it's certainly ugly, the easiest way to solve the problem at present is to version all of your unittest blocks with a version identifier specific to your project. That way, any projects depending on your library won't actually end up compiling the unittest blocks, because while the unittest version identifier will have been declared, the version identifier specific to your project will not have been. There was actually a PR for Phobos a few months back that tried to do this to all of Phobos to fix this problem with Phobos, but it was rejected on the grounds that it was hideous and that we should solve it in the language - which I agree with, but in the interim, we still have to deal with the problem - hence why dxml has the dxmlTests version identifier. Without it, any projects using dxml would get linker errors when running their own tests.

Where dub makes this whole situation worse is that for some reason, the build configuration for your library that's used when you run dub test is also used by anything that pulls in your library via dub. I had made it so that dub test declared dxmlTests so that dub test would work properly for dxml but with the idea that then any projects depending on dxml would not declare dxmlTests. However, because dub pulls in the dependencies' unit test configurations instead of just using the non-unit test one like it should, that results in any projects that depend on dxml having dxmlTests declared, so the problem isn't fixed, and all of those annoying version(dxmlTests) blocks were a waste of time.

To workaround this stupidity of dub, I was forced to create a separate set of buildTypes for running the unit tests in debug, release, or with code coverage. Those buildTypes must be used, or there are no unit tests, meaning that dub test goes really fast and does nothing useful whatsoever. And because of this whole issue, I avoid dub test like the plague.

So, dub needs to fix what it's doing (I can't remember what I reported at the time - I really should make sure that I have all of the facts straight and clearly explained in a bug report for dub), and once it is fixed, then dub test can be used again by projects that need to do custom stuff with their unit test configurations. But that still leaves the compiler problem, and a DIP needs to written to fix that. IIRC, Jonathan Marler was trying to fix it several months ago, but I think that he was mucking around with version(unittest) in general, and he ran into all kinds of weird problems. So, I don't know what it would really take to fix the problem in the compiler, but I think that it's pretty clear that unittest blocks should be utterly ignored when the module they're in is imported, and right now, they're not.

- Jonathan M Davis

On Saturday, September 8, 2018 7:28:53 AM MDT Nicholas Wilson via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
> > 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
>
> How would this work for packages that cannot be built by DMD? Or that have no CI infrastructure but are maintained? *cough* DCompute *cough*

A related issue is projects that have dependencies outside of D itself
- for instance, a project that wraps GTK or Qt or something C or C++ library
that is on many systems but which isn't guaranteed to be present. It would
be trivial to end up with packages being marked as unmaintained or not even
working at all when in reality, they work just fine. It's just that they
require more than just dub and the D compiler to work.

These problems aren't necessarily insurmountable, but they do complicate the things. And while we do want to provide better information about what is and isn't working and maintained, we also don't want to be marking projects as not working when they actually work just fine

- Jonathan M Davis