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

[Ola Fosheim Grøstad]

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. The problem is when there are breaking changes in a 
package used by a package used by a package. This can happen if 
the versioning-condition wasn't fixed, or if a package's package 
requirements are updated and the application relies on features 
of an indirect dependency (e.g. you import a "webserver package" 
and depend on the interface of objects from an indirectly 
imported "json package").

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.

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. If you use a larger 
javascript project you risk having many different versions of the 
same type of functionality because different packages pull in 
different (but similiar) dependencies! So I usually choose not to 
import npm-packages, only larger ones that are maintained by 
professional teams (e.g. angular), then those teams can deal with 
the deep-import npm-dependency-sillyness so I don't get burned.

For Python it usually works ok, but I think that is because the 
programming environment in Python is very stable ("virtual 
machine") and commonly packages usually don't change drastically 
most of the time. Also the user base is so large that breaking 
changes are detected. You can make the same arguments for Go, as 
it is also to a large extent a "self sufficient virtual 
machine/environment".

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