Recommendation on plotting library

[Greggor]

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.