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?

On Wednesday, 13 September 2017 at 19:55:03 UTC, jmh530 wrote:
> 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?

No you are not, it's just currently a bit painful to do manually due to e.g. missing support for git submodules.
However, some projects already do this:

Windows: https://github.com/ariovistus/pyd/blob/master/dub.json

And for Linux it's even possible to compile small dependencies on the fly:

https://github.com/dlang-community/drepl/pull/63

Imho if the library is small, compiling it (or using prebuilt for Windows), should be the default behavior because it's a very pleasant user experience

On Wednesday, 13 September 2017 at 22:50:54 UTC, Seb wrote:
>
> No you are not, it's just currently a bit painful to do manually due to e.g. missing support for git submodules.
> However, some projects already do this:
>
> Windows: https://github.com/ariovistus/pyd/blob/master/dub.json

I was not aware that pyd does that, but it is very similar to what I'm saying.

The difference would be to put the .lib files in a separate dub project. Instead of having the dub.json pointing to the location of the lib files within the pyd project, there would be a dependency on the lib project and a link to the files within that.

I suppose there is no real reason why there needs to be a wrapper. This behavior can get added to D bindings.

Regardless, I suppose the main motivation of not putting it in the bindings is that if someone is using the library on Linux, then they don't need to download any of the Windows lib files. The only change would be a small change to the dub.json to account for the different Windows behavior.

>
> And for Linux it's even possible to compile small dependencies on the fly:
>
> https://github.com/dlang-community/drepl/pull/63

I'm specifically interested in good support for Windows.

>
> Imho if the library is small, compiling it (or using prebuilt for Windows), should be the default behavior because it's a very pleasant user experience

I'm 100% pro-"very pleasant user experience." The problem is that it usually isn't on Windows in this case. You often have to go find the library yourself and existing pre-built ones may not be in the right format (How were they compiled? MinGW or MSVC? What linker? Etc) so you have to go build it yourself. Deimos projects, for instance, are just C headers and D bindings. No .lib files.