On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter wrote:
> On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
>> On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany wrote:
>>> On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
>>>> [...]
>>>
>>> You showed as a painful issue in our eco system which we can work on, thank you.
>>>
>>> You do not need to work on this but do you have a proposal for a solution? What would you help (ranking according to last update, ...)
>>>
>>> Kind regards
>>> Andre
>>
>>
>> The problem is that all projects should be maintained. The issue, besides the tooling which can only reduce the problem to manageable levels, is that projects go stale over time.
>>
>> This is obvious! You say though "But we can't maintain every package, it is too much work"... and that is the problem, not that it is too much work but there are too many packages. This is the result of allowing everyone to build their own kitchen sink instead of having some type of common base types.
>>
>> It's sort of like most things now... say cell phone batteries... everyone makes a different one to their liking and so it is a big mess to find replacements after a few years.
>>
>>
>> See, suppose if there were only one package... and everyone maintained it. Then as people leave other people will come in in a continual basis and the package will always be maintained as long as people are using it.
>>
>> This is why D needs organization, which it has none. It needs structure so things work and last and it isn't a continual fight.
>>
>> It's like if someone doesn't take care of their car. Eventually it starts to break down and when they do shitty fixes it only buys them a little time before it breaks down again and again.
>>
>> The issue isn't the fixes nor the car but how they use the car and not maintain it properly. That is, it is their mindsets. Since D seems to be full of people with very little understanding how how to build a proper foundation for organization, D has little chance of surviving. As the car breaks down more and more it is just a matter of time before it ends up in the junk heap. It was a great car while it lasted though...
>
> That's what I have said elsewhere in the thread. Checking the maintainer of a package, if there's no feedback, put the package out of the main list and put it in a purgatory where it can get stale for itself. If a new maintainer appears for a specific package, it can be reinstated in the approved list when it works again.
> 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.

The more the compilers and tools do for us the easier our life becomes. The more complex things get the more time it takes. Since most things tend towards complexity it means things should be designed well from the get go before they become mainstream so messes like this do not happen.

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!

On Thursday, 6 September 2018 at 16:27:38 UTC, Everlast wrote:
>
> You totally missed the point.
>
> The point with 1 package only was to demonstrate how easy it is to maintain and that it theoretically would have the long longevity. When one has an infinite number of packages then every package(or almost everyone) would rot very quickly.
>
> I didn't say there should actually only be one package, as that is absurd. What I said was that because D has no organizational structure to focus work on a fewer number of better maintained and designed packages there is a ton of shit out there for D that doesn't work but there is no way of knowing and not always an easy fix because it takes time to understand the code or it is simply defunct.
>
> This is not rocket science...

I know that you wanted to talk about easier maintenance. But what exactly is that D organization going to do ? Prevent people from making more packages and force them to work on theirs instead ?
No matter if there is an organization, there will always be unofficial packages going stale. You sound like it's going to be a magical solution.

On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
> To me, this strongly suggests the following idea:
> - add *all* dlang.org packages to our current autotester / CI
>   infrastructure.
> - if a particular (version of a) package builds successfully, log the
>   compiler version / git hash / package version to a database and add
>   a note to dlang.org that this package built successfully with this
>   compiler version.
> - if a particular (version of a) package fails to build for whatever
>   reason, log the failure and have a bot add a note to dlang.org that
>   this package does NOT build with that compiler version.
>    - possibly add the package to a blacklist for this compiler version
>      so that we don't consume too many resources on outdated packages
>      that no longer build.
> - periodically update dlang.org (by bot) to indicate the last known
>   compiler version that successfully built this package.
> - in the search results, give preference to packages that built
>   successfully with the latest official release.

Yes please!

On Thursday, 6 September 2018 at 18:20:05 UTC, Bastiaan Veelo wrote:
> On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
>> To me, this strongly suggests the following idea:
>> - add *all* dlang.org packages to our current autotester / CI
>>   infrastructure.
>> - if a particular (version of a) package builds successfully, log the
>>   compiler version / git hash / package version to a database and add
>>   a note to dlang.org that this package built successfully with this
>>   compiler version.
>> - if a particular (version of a) package fails to build for whatever
>>   reason, log the failure and have a bot add a note to dlang.org that
>>   this package does NOT build with that compiler version.
>>    - possibly add the package to a blacklist for this compiler version
>>      so that we don't consume too many resources on outdated packages
>>      that no longer build.
>> - periodically update dlang.org (by bot) to indicate the last known
>>   compiler version that successfully built this package.
>> - in the search results, give preference to packages that built
>>   successfully with the latest official release.
>
> Yes please!

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.

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

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

On 09/06/2018 09:12 AM, Steven Schveighoffer wrote:

> The compiler doesn't change all that often, and when it does, it's usually a long deprecation cycle.

Even with perfect backwards compatibility in the compiler, minimum compiler version will still tend to matter. Also, cherry-picking specific 2.x.0 versions that are known to not work due to regressions.

> The problem really is that phobos/druntime change all the time. And they are tied to the compiler.

True enough.

> I think some sort of semver scheme really should be implemented for the compiler and phobos. But we need more manpower to handle that.

Fair point on manpower.

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

my 2 ¢

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.