On Friday, 21 July 2023 at 15:12:57 UTC, Jonathan M Davis wrote:
> On Friday, July 21, 2023 1:03:47 AM MDT Chris Piker via Digitalmars-d-learn wrote:
>> On Friday, 21 July 2023 at 06:15:10 UTC, Jonathan M Davis wrote:
>> > On Thursday, July 20, 2023 10:57:22 PM MDT Chris Piker via Digitalmars-d-learn wrote:
>> >
>> > Regardless though, dub really isn't designed with packaging anything in mind. Rather, it's designed to build your code as well as pull in D libraries that it usees and build those too. Anyone looking to actually package stuff would create a package from what was built with dub (e.g. with deb, rpm, flatpacks, etc.).
>>
>> So as far as I can tell, python pip originally only dealt with
>> python code, but eventually wheels were added for binary support.
>>   Just as a wild guess, do you see dub ever evolving in that
>> direction?  All the reasons for not supporting pre-compiled
>> binaries in pip apply to dub, but yet support was added anyway,
>> and it's been wildly successful.
>>
>> I know it's hard to make predictions (especially about the future), but I'd be interesting in your opinion on the matter.
>
> I'd be very surprised if dub added support for pre-compiled binaries - particularly since D isn't generally binary compatible across releases - but I really don't know what the folks working on dub want to do with it.
>
> - Jonathan M Davis

Dependency management sucks for windows and I understand wanting the ability to just do dub run and have it “just work tm”.

Up to date versions of Windows 10 should have curl included and dub can run commands before building, so you could try downloading a prebuilt lib for windows via curl. https://everything.curl.dev/get/windows

On Friday, July 21, 2023 11:40:25 AM MDT Greggor via Digitalmars-d-learn wrote:
> >> So as far as I can tell, python pip originally only dealt with python code, but eventually wheels were added for binary support.
> >>
> >>   Just as a wild guess, do you see dub ever evolving in that
> >>
> >> direction?  All the reasons for not supporting pre-compiled binaries in pip apply to dub, but yet support was added anyway, and it's been wildly successful.
> >>
> >> I know it's hard to make predictions (especially about the future), but I'd be interesting in your opinion on the matter.
> >
> > I'd be very surprised if dub added support for pre-compiled binaries - particularly since D isn't generally binary compatible across releases - but I really don't know what the folks working on dub want to do with it.
> >
> > - Jonathan M Davis
>
> Dependency management sucks for windows and I understand wanting the ability to just do dub run and have it “just work tm”.
>
> Up to date versions of Windows 10 should have curl included and dub can run commands before building, so you could try downloading a prebuilt lib for windows via curl. https://everything.curl.dev/get/windows

Well, from what I recall (though it's been a while since I messed with anything like it), it's possible with dub to run more or less arbitrary stuff (e.g. use cmake from dub). It's a pain, but it can be done. And if that's the case, then you should be able to design a dub project that pulled in pretty much whatever you want with curl. And simply being able to build and run a D program as part of the build would be enough to be able to use curl in general without Windows having added it, since dmd comes with it because of std.net.curl. But of course, that's a rather different thing from dub providing a clean way to handle that sort of thing.

dub can do a lot, but because it's really not designed around doing much beyond pulling in dependencies from code.dlang.org and then building all of the code, doing stuff beyond that gets to be problematic even if it can be done. So, if we wanted something more fully featured, then dub would need a bit of an overhaul. And maybe dub will get that at some point (I don't know), but as things stand, if anyone really wants to do complex stuff with their builds, dub can be pretty awkward to use. And that's why projects such as https://code.dlang.org/packages/reggae exist, though it's geared more towards providing a more fully-feature build system than providing a way to pull in pre-built binaries and the like. What additional features we get in the future will likely be highly dependent on how motivated the people are who want dub to be able to do more.

- Jonathan M Davis

On Friday, 21 July 2023 at 17:40:25 UTC, Greggor wrote:

> Up to date versions of Windows 10 should have curl included and dub can run commands before building, so you could try downloading a prebuilt lib for windows via curl. https://everything.curl.dev/get/windows

Hey, nice!  This might be a winner.  Unless I'm missing something libcairo-2.dll, libpng13.dll and zlib1.dll could be downloaded, and then ggplotd plot can build against those (probably?).

The key thing that dub is missing compared to pip is some concept of an "install" directory.  Compared to everything else dub handles, not adding this capability mostly comes down to self imposed limitations.  I wonder how many in the community would like to see those limitations removed?

I presume it's just as easy to add commands that run after the build as before.  I could have an alternate dub configuration that's short for "setup_build_test_install" that runs everything.

If multiple projects start defining an install target the same way, then you have a convention, which can eventually lead to a standard.

On Friday, 21 July 2023 at 22:51:16 UTC, Jonathan M Davis wrote:
> On Friday, July 21, 2023 11:40:25 AM MDT Greggor via Digitalmars-d-learn wrote:
>> >> So as far as I can tell, python pip originally only dealt with python code, but eventually wheels were added for binary support.
>> >>
>> >>   Just as a wild guess, do you see dub ever evolving in that
>> >>
>> >> direction?  All the reasons for not supporting pre-compiled binaries in pip apply to dub, but yet support was added anyway, and it's been wildly successful.
>> >>
>> >> I know it's hard to make predictions (especially about the future), but I'd be interesting in your opinion on the matter.
>> >
>> > I'd be very surprised if dub added support for pre-compiled binaries - particularly since D isn't generally binary compatible across releases - but I really don't know what the folks working on dub want to do with it.
>> >
>> > - Jonathan M Davis
>>
>> Dependency management sucks for windows and I understand wanting the ability to just do dub run and have it “just work tm”.
>>
>> Up to date versions of Windows 10 should have curl included and dub can run commands before building, so you could try downloading a prebuilt lib for windows via curl. https://everything.curl.dev/get/windows
>
> Well, from what I recall (though it's been a while since I messed with anything like it), it's possible with dub to run more or less arbitrary stuff (e.g. use cmake from dub). It's a pain, but it can be done. And if that's the case, then you should be able to design a dub project that pulled in pretty much whatever you want with curl. And simply being able to build and run a D program as part of the build would be enough to be able to use curl in general without Windows having added it, since dmd comes with it because of std.net.curl. But of course, that's a rather different thing from dub providing a clean way to handle that sort of thing.
>
> dub can do a lot, but because it's really not designed around doing much beyond pulling in dependencies from code.dlang.org and then building all of the code, doing stuff beyond that gets to be problematic even if it can be done. So, if we wanted something more fully featured, then dub would need a bit of an overhaul. And maybe dub will get that at some point (I don't know), but as things stand, if anyone really wants to do complex stuff with their builds, dub can be pretty awkward to use. And that's why projects such as https://code.dlang.org/packages/reggae exist, though it's geared more towards providing a more fully-feature build system than providing a way to pull in pre-built binaries and the like. What additional features we get in the future will likely be highly dependent on how motivated the people are who want dub to be able to do more.
>
> - Jonathan M Davis

I'll be honest, I actually really don't want this, pip and especially prebuilt wheels deps have often made my life miserable. On the linux side of things. Pulling in dynamic libraries that are not from the distro package manager or freshly built locally is simply not a good idea. Things like different stdlibC(s) will break even the simplest of things.



Python is actually a good example of what NOT to do, I don't program in python so take what I am about to say with a grain of salt. But not too long ago I installed onto my machine stable diffusion and it was a harrowing process that perfectly encapsulates my problems with the python ecosystem. Building the deps from source was broken and the prebuilt deps where not matching my distro's python version. I tried all sorts of things like venv and building as much stuff locally all the other "correct" ways and nothing worked.

Eventually I went down a path of super jank and essentially frankensteined a working runtime by hand. I built a specific version of python from src and installed it to its own folder, I used a bunch of LD env vars and used patchelf on deps to basically make an isolated install of python and glued together a bunch of the native pre build packages, because building them on my machine was a pain.

What should of been a simple "pip install X" is now a cargo cult-ed install. I dread the day when it will stop working.

Whats even more upsetting is that non of it is some ancient out of date packages, it's all popular and maintained stuff. Maybe part of the problem is that I when I say "linux", I am not referring or implying some version of Ubuntu and that my understanding of the word includes distros that use different stdlibC(s) and could also not use things like system-D.

Despite the amount of users and active support, I guess a lot of headaches related to building are flying under the radar due to pre-built packages.



Comparing this with Dub & D is a night and day difference, the current ecosystem is very easy to use and has little issues, even with our smaller community.

I feel comfortable that anytime I ran into an issue with a dependency that making a change is easy. To do so is as simple as pulling it down into a folder and then editing a dub.json/.sdl to point to the path of the edited version. If it worked before I needed to make a change I know it will work after, there is no question of "will I be able to build it". Whats also nice about this is that fixing an issue locally has a few times turned into me making an upstream contribution. (this is really good for a smaller community)

In general whenever possible I think its better for everyone that stuff is built from source. It ensures that builds can be re-produced by anyone and that issues with building are caught fast by anyone consuming the library.



While I don't have a ton of experience working on the windows side, there is no good package manager & DLL(s) work a bit differently and don't have the stdlibc issues or having a bunch of different distros to target. It's relatively normal for a program to just ship with a couple of DLL(s) along side the main executable. Hence my recommendation of the curl hack for windows.

TL;DR I understand the issue trying to solved on the windows side and I think the positives are stronger then the negatives in the windows case. But I do not want my suggestion to be mistaken for general support for pre build binaries being distributed by DUB. Out side of this case I am actually very strongly against this idea.