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

[FeepingCreature]

On Saturday, 23 April 2022 at 20:15:27 UTC, deadalnix wrote:
> Why do we use a package manager that expect everyone to use it 
> to work in a certain way? It is blatantly obvious that many 
> organization out there are not going to use the exact setup dub 
> expects. So what do they do if they want to adopt D? Not use 
> dub at all? It's an option, but everything is distributed via 
> dub nowadays in the D ecosystem. Use dub to build everything? 
> Fork their own version of dub? No, the only sensible path 
> forward for pretty much any organization stumbling on this 
> bullshit is to not use D at all because none of the crap we put 
> out there is going to play nicely with what they already have.
>

Just shell out to dub as required. That's what we do.

I disagree with this post. Dub's requirements seem eminently 
sensible to me, if you publish source code without a license, 
you're basically setting a copyright trap for the unwary. I 
disagree with the v1.2.3 format but it's explicitly called out as 
a common choice in the semver spec. And dub's goal should be to 
be simple first, composable second. Why make dub shell out to 
another build system? If you want to use another build system, 
just build with that system. Dub is off in its own little world 
of D packages, and that's fine, it limits the breakage surface, 
encourages internal standardization and makes it easy to get 
started for a newcomer. Imagine if you run 'dub build' and it 
told you to install meson (because some dependency needed it), 
you'd be weirded out, right? "So is Dub the D build system or 
meson?" Imagine needing to install *multiple* build systems. I'm 
glad that dub doesn't enable that sort of mess.

It's okay to not have a feature sometimes.