On 4/26/22 5:38 PM, deadalnix wrote:

I'm perfectly fine with projects not using dub. Don't listen to people who cry about dub usage.

And I lead projects that use dub. People have asked me to include meson build files in some cases. And I've obliged, but I hate maintaining it (most important reason -- meson build file must be manually updated to match git tag). I'd rather just get rid of them, and if you don't want to use dub to build my projects, then roll your own fork.

Don't use dub, no enlightenment necessary.

I'm not. I said this from my first post on this unreasonably long thread, I don't care what you use, D does not require you to use dub to build.

-Steve

On Tuesday, 26 April 2022 at 22:08:27 UTC, Steven Schveighoffer wrote:

You are missing the important part. Because dub do not play nice with anything else, that means we might as well use a different language. My D code can never talk to your D code without an absurd amount of time, energy and effort expanded.

You apparently had a small taste of that with meson. I ended discarding meson as an option for reason similar to dub - and reasons you are experiencing now: meson doesn't play nice with other kids.

Except meson is kinda asocial, while dub is more like the Westboro Baptist Church.

On Tuesday, 26 April 2022 at 07:37:42 UTC, Ola Fosheim Grøstad wrote:

No more than anything else like maven, linux package managers, chocolatey on windows. I hear vcpkg also supports prebuilt binaries now but I think it is only for private registries, they're not hosting them. Vcpkg is focused on build from source not because of security concerns but ABI and compiler compatibility.

It is also fairly easy, much more than pip or maven, to set up your own package registry server so it never goes out to he official hosted service for packages.

When you invoke conan, or in your config file, you can tell it to only build from source so it will not download the binary package even if available.

On 4/26/22 6:50 PM, deadalnix wrote:

Define "absurd". You want to include version flags that might be in my dub file? They are in there, not hard to read. You want to include the library? Build with dub build in my repo, and then you have the lib available. All my files are in my source directory. Is that hard to use?

Dub does not use extraneous build pieces. All it does is construct a valid compilation line. You can mimic that line without (IMO) an absurd amount of effort.

With dmd -i, you can pretty much just ignore dub and just use the proper -I directories, I can't imagine this will be extremely difficult.

None of this is to say that it's not work, or that it's seamless. But it's not any less seamless than if dub didn't exist.

Nah, my experience was never with using meson, my experience was with CI and meson. In other words, I'd update my library, tag it, and it's ready for dub. But meson also needs me to duplicate the tag in its build file, or it doesn't work. That is junk. Imagine this workflow:

1. create your update
2. Use CI on your PR, it works
3. Merge to master
4. Tag for release
5. Master CI now breaks because meson wasn't satisfied.

i.e. you can't run CI until you've tagged the release.

I asked, can you make Meson automatically use the tagged version? Answer is no. So I really am regretting merging that file, and probably will just take it out of CI unless someone cares.

This is an insanely overexxagerated analogy.

-Steve

On Tuesday, 26 April 2022 at 23:48:03 UTC, norm wrote:

I think it comes down to credible management and vetting strategies. My impression from Debian stable (when I used it regularly) was that they took security very seriously and made it hard for rogue binaries to make it into the repo. It also helps to have a million critical and skilled users that are eagerly looking for flaws!

In contrast, I am much more critical of pip/Python and either avoid less known packages from pip or vet the code before executing it.

Thanks, I might have look at Conan then… :)

(I guess it is ok if the binaries are reproducible and built on a secure cloud solution and not by individual contributors, but it still sounds like a risk to my ears.)

On Wednesday, 27 April 2022 at 00:51:08 UTC, Steven Schveighoffer wrote:

What it boils down to is that it is beneficial for the eco system that all D users have an equal opportunity to share and market their projects through the official channels.

Maybe Dub should be a brick in a larger system, rather than the opposite. That way people with simple needs can stick to Dub and people who draw on non-D resources can get equal opportunities.

Some sort of extensible agnostic meta-packaging system that can draw in resources from Conan, Dub etc.

On Wednesday, 27 April 2022 at 06:48:48 UTC, Ola Fosheim Grøstad wrote:

Seems like vcpkg has expanded their scope, by automatically downloading compilers, linkers and SDKs for embedded development:

https://devblogs.microsoft.com/cppblog/vcpkg-artifacts/

Not sure how they plan to ensure the quality/security of this approach, but I guess Microsoft can afford to pay staff to do the auditing (if they do it).

It would be a grave mistake to try to replicate any of this for a small player like the D community. It would be better to get LDC and other dependencies into vcpkg.

On Tuesday, 26 April 2022 at 12:47:56 UTC, Ola Fosheim Grøstad wrote:

Indeed, not native. Are you suggesting Dub should include winget?

-- Bastiaan.