I just created a dub package. Frankly, the whole thign is backward.

[Guillaume Piolat]

On Monday, 25 April 2022 at 11:47:17 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 25 April 2022 at 11:15:59 UTC, Guillaume Piolat 
> wrote:
>> For example, if I fix issue 
>> https://github.com/AuburnSounds/Dplug/issues/642 and release a 
>> new DUB tag, you get this bug fix without even knowing the 
>> problem existed, at your next "dub upgrade". For the user of 
>> the library, it doesn't enter their consciousness and they can 
>> go on with their lives not caring about what this is, or which 
>> commit they should look at.
>
> This can be problematic, sometimes people hardcode a way around 
> library bugs and things will go wrong if they are silently 
> fixed. I'd rather not having bugs silently fixed if I use a 
> library for something significant.
>
>> Because dependencies are nested, and reused across 
>> people/organizations, this happens at various levels hence 
>> improving cost effectiveness of development.
>>
>> Things like DUB and NPM replaces attention by trust.
>
> In theory.

Not in theory.
If you won't trust anyone you can live in your own packages and 
it's all in your control.
But by foregoing some degree of control you save on debt.

> The problem is when there are breaking changes in a package 
> used by a package used by a package.

Then it is a breach of trust and upstream should stop depending 
on it.

> Such things happen, like I had this experience with a widely 
> used web server library for Python called "Flask" that imports 
> a library called "itsdangerous". The condition Flask used for 
> "itsdangerous" was >= some.required.version. So it worked well 
> on local testing, but when it was uploaded to the cloud the 
> cloud service retrieved a more recent version of "itsdangerous" 
> and it failed to run.

You should never use >= without <=. It is so basic I'm surprised 
a popular framework would do it. Nothing prevents people from 
using Semver correctly. Like OOP.


> In the npm environment the problem is much larger as javascript 
> authors go out of their way by importing various libraries for 
> even the most trivial functionality.

Yeah we don't have that in D.
But I've seen something similar in Rust, hundreds of packages 
because small stdlib.


> If you use a larger javascript project

Thankfully this concerns the Javascript ecosystem, and not the D 
ecosystem.

> Now, you might not see these issues in the use of Dub until 
> there are many packages that depends on each other.

And at this point (IF this happens with D) this isn't a problem 
with DUB, but a community problem.