On Tuesday, 22 March 2022 at 14:44:59 UTC, Marcone wrote:
> Why is dmd unable to import modules installed by dub using the import command like it does with the Phobos library? He can't send these modules to Linker? Needing to be passed to dmd via command line. I think it could be all automatic.

dmd CAN do that.

dub CHOOSES not to use this capability.

This is a big reason why I hate dub so much. It doesn't use D's strengths at all.

On Friday, 18 March 2022 at 18:16:51 UTC, Ali Çehreli wrote:
>
> The first time I learned about pulling in dependencies terrified me. (This is the part I realize I am very different from most other programmers.) I am still terrified that my dependency system will pull in a tree of code that I have no idea doing. Has it been modified to be malicious overnight? I thought it was possible. The following story is an example of what I was exactly terrified about:
>
>
> https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
>
> Despite such risks many projects just pull in code. (?) What am I missing?
>

This is an interesting observation and something of an oddity in modern SW engineering. I have been on several projects where they just download versions of libraries from some random server. For personal projects I guess this would be ok but for commercial software this would be a big no-no for me. Still the trend goes towards this. Now, several build systems and packet manager software have the possibility to change the server to a local one. Changing to local one is unusual though which is strange.

First as you mentioned is that you increase the vulnerability by the possibility injecting a modified version of a library with back doors. Then you also become dependent on outside servers which is bad if they are down.

In all, for commercial software just avoid dub. If you want to use a build system go for Meson as it has D support out of the box today. For commercial projects pull libraries manually as you want to have full control where you get it, the version and so on.

On Tue, Mar 22, 2022 at 05:36:13PM +0000, IGotD- via Digitalmars-d-learn wrote:
> On Friday, 18 March 2022 at 18:16:51 UTC, Ali Çehreli wrote:
> > 
> > The first time I learned about pulling in dependencies terrified me.
[...]
> > https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
> > 
> > Despite such risks many projects just pull in code. (?) What am I
> > missing?
> > 
> 
> This is an interesting observation and something of an oddity in modern SW engineering. I have been on several projects where they just download versions of libraries from some random server. For personal projects I guess this would be ok but for commercial software this would be a big no-no for me. Still the trend goes towards this. Now, several build systems and packet manager software have the possibility to change the server to a local one.  Changing to local one is unusual though which is strange.
[...]

To be fair, even though I'm clearly on the side of not depending on external resources, there are various reasons why one might prefer to go the route of dub / the modern trend of package managers that depend on external resources.

- It alleviates the tedium of having to manually maintain local archives
  of 3rd party packages. When the code is needed, it gets downloaded
  from the upstream servers. The package manager (dub in this case)
  manages the local cache for you.

- You get updates automatically. If there's a critical security fix, for
  example, you'll get it upon the next build, you don't even have to be
  aware of the existence of the security flaw and its fix to reap the
  benefits.  When a new feature is made available upstream, you don't
  have to manually download the latest version to reap the benefits, you
  get it automatically upon the next retrieval of the package.

- It's very convenient: you don't have to know where the upstream
  servers are, how to download it, where to store it -- the package
  manager handles that all for you. You just specify which packages you
  want, and it takes it from there.

Of course, as with programming projects in general, convenience often comes at a price.  The security flaws that crop up, for example, which, in today's threat landscape, are much more frequent and important than a decade ago, and worthy of some very serious consideration. While automatic downloads do get you "automatic" security fixes, it also introduces potential security holes (trojan attacks, MITM attacks, etc.).

Also, the long-term consequences of convenience. A lot of the benefits of external dependencies are short-term benefits; over the long term, they get outweighed by long-term maintenance issues, like the ones I mentioned in my other post (long-term compatibility, breaking changes, availability, etc.).


T

-- 
Only boring people get bored. -- JM