I'm not sure this makes much sense, but it's something that's
been rolling around in my head the past 2-3 days.
One of the great things about Python's Anaconda is that you just
download one file, install and it just works. In D, dub offers
comparable functionality as conda, which is very helpful. Usually
it doesn't take much to get up and running with dub. This is
especially true with projects that only use D code. However,
things can get a little more complicated when a dub project in
turn depends on some C library or something. I think this
particularly applies to static binding. In my experience, it's
usually far easier to deal with these sorts of issues with Linux
than Windows. This additional difficulty likely would make it
less likely that some Windows user would switch from Python to D.
To reduce this difficulty, given some C library that already has
D bindings available, I would start a separate dub project that
just includes the .lib or .dlls necessary for Windows. Then, a
wrapper (or more generally, any library that uses the bindings)
could then have a dub sub-configuration such that Windows
requires the previous dub project and uses it for dll/libs (also
including a switch that would allow the user to put the path to
them manually).
This way the user could download the D binding themselves and do
things manually, or they could use the wrapper and have a "just
works" experience on Windows (with the option for manual
customization).
Am I making sense here? Anything I haven't thought of?
