On Monday, 25 April 2022 at 10:41:35 UTC, user1234 wrote:

My point was just this: gnu make is available on most developer setups (or easy to get hold of) so using that from Dub ought to be easy, but most applications that use make also use an auto-config layer on top of that. I doubt most Dub authors will be able to make good use of auto-config, so encouraging the use of make might create more issues than it solves. Not because make is complicated, but because autoconfig setups might require testing on many platforms.

It might be better to build on top of a package manager for C/C++ and find a way to reuse that in a way that autoconfigs an existing C/C++ package in such a way that it works with "import C".

D needs to focus on reducing the need for manpower, so reusing other eco systems makes good sense, but how to do it? That is far from clear, but there are some emerging options in the C/C++ community that could be investigated.

On Monday, 25 April 2022 at 09:20:23 UTC, Ola Fosheim Grøstad wrote:

The reason seasoned developers use things like DUB is not ease of building, but debt control.

With Semver you will get bug fixes while you sleep.
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.

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.

On Monday, 25 April 2022 at 11:15:59 UTC, Guillaume Piolat wrote:

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.

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.

On Monday, 25 April 2022 at 11:47:17 UTC, Ola Fosheim Grøstad wrote:

Another great example, or even more infamous example would be this:

https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

There are a couple more examples like the above, most notably it has happened to NPM the most.

On Monday, 25 April 2022 at 11:47:17 UTC, Ola Fosheim Grøstad wrote:

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.

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

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.

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

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

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

On Monday, 25 April 2022 at 12:11:48 UTC, Guillaume Piolat wrote:

You can use dplug Dub for prototyping and switch to using a github fork if you release it, then you get to track all changes in detail on your own private fork.

Most programs are "personal prototypes", so one can use both, sure.

All I can say is that I wasn't pleased when small trivial tweak on the webserver turned into a longer debugging-session… (I wasn't planning on upgrading anything, just wanted to add a line of code.)

On Monday, 25 April 2022 at 12:03:13 UTC, bauss wrote:

You also have the issue of checking indirect imports for bad or malicious code. Which is why I avoid npm for the most part, at some point it will be used for "cyber warfare" or mischief. It is only a matter of time as the attack vector is so accessible and obvious.

(It is very difficult to vet code you build on when it is pulled in by package managers.)