On 09/10/2013 19:25, Jacob Carlborg wrote:

On 2013-10-09 08:00, Sönke Ludwig wrote:

There have been ideas in that direction in
#52 and
#34 and also in
some earlier discussions (need to search for those). However, there
have been strong objections from package maintainers regarding the
feasibility or hygiene of this approach in general.

I agree it's a very ambitious side project. However maybe there is
some middle ground solution where at least a customized error message
can be output in case of a missing library. In our case, external
libraries of this kind ideally should only occur for Deimos(-like)
modules, so it's not unrealistic that there will be good broad support
for this solution, even if it requires manual work.

I'm wondering how difficulty it would be to support external
dependencies. Something like:

"external" : {

 "curl": "1.2.3"


The tool would then just run "apt-get install curl", "port install curl"
or whatever the native package manager is for the given platform.

The problems I see with this is that Windows doesn't really have a
package manager. Mac OS X doesn't have one installed by default but I
think it's ok rely on Homebrew and MacPorts.

The other problem is package names. Different package manager might use
slightly different names for the same packages. Also MacPorts support
variants where other package managers might require a separate package.

These solutions involving dub using external/system package managers
don't feel right at all... I think this is a wrong approach.

Doesn't using external libraries imply you need a D binding/import
anyways? As such doesn't it follow that it is best that an external
library be wrapped by a dub-package? Here's the idea:
The dub-package wrapper would include the library binaries (for all
available platforms) and the respective D imports/bindings. This would
make the library available for dub usage in all platforms, with no
reliance on system package managers (thus, cross-platform).
If a newer version of the library is made available (say, you have a
dub-package for curl-1.2.3 and now 1.2.4 is out, then the dub-package
will have to be manually updated. Some auxilary tool could be used to
help with this process. This tool could potentially interact with a
system package manager, but it would be separate from dub (or sitting at
a higher level in the toolchain).

This approach requires more work to update libraries when new versions
arrive, but it's easier to implement (dub-wise) and provides a clean
platform-independent abstraction, because dub remains independent of
system package managers.
I think it's a worth tradeoff. In any case, any library updates other
than service-level version updates will (or should) require an update to
the D bindings since it means the underlying API has changed.

Bruno Medeiros