More dub 2.0 idea refinement

Core D Development Statistics

• 12 bugs fixed
• 19 bugs and enhancement requests opened
• 19 pull requests merged into the language: 12 into DMD, 1 into Phobos, and 6 into druntime.
• 2 pull requests merged into the website.

In the community

Community announcements

• Beta 2.100.0
• mysql-native v3.2.0 - the safe update

See more at the announce forum.

More dub 2.0

A big question will be: how does it interact with existing codebases? Remember, as far as the package manager is concerned, it wants two end results: some .d files it can compile/import and (optionally, if the .d files compiled don't produce them) lib files it can link. There should be extreme flexibility in how you get there, including possibly a fallback stack.

In web css, you can provide a list of fonts and it uses the first one that's available. These fonts might be pre-installed or downloaded or even pulled out of the user's substitutes configuration.

I think something similar to that might be useful for fallback dependencies. This might be defined directly by your application, or by the dependency itself. For example, a dependency might be on gtk. The gtk dependency can have a fallback stack similar to: first, use the gtk version provided by the operating system. If that isn't there, second, try downloading a pre-built binary from a website. If that fails we could try compiling it (which probably depends on autoconf and make and friends...).

The user code might even go another step and say if gtk fails, go ahead and try an entirely different library. This would be a good case for propagating some version flags to the top level, similar to dub 1.0's Have_package specifiers, so you know which one got selected, though I would also like to use my config module pattern described in my book: building the library can generate a module library.config; that you can import and check standard values, and can also define flags and such to easily abstract (indeed, the config module might be imported and run by some kind of pkg-config type thing to give that info by a standardized driver). So long as you implement the interface, it is not too important how - I want to keep the build system flexible and decoupled. These might even just forward to pkg-config via executeShell for a system package on certain platforms!

Aside - running code and security

Using executeShell brings up a point about running code as part of a build. I'd point out this is pretty common: configure scripts are shell scripts. Makefiles can run arbitrary commands. pkg-config is a program you execute. Many package managers download and run things.

And of course, you are likely to run the built program, which means whatever in its source can go off too.

So I'm not really concerned about it. That said, of course, you'd ideally want the code to be declarative anyway rather than wide open, just sometimes you gotta do other things to interface with the system and I expect holes will be punched anyway. I prefer to look at incentives than restrictions: make the best thing to do the easiest thing to do.

Cross compilation

One point people have brought up is if you allow any build system, cross compilation may become more difficult. This is true, we probably want to define the target arch and compiler preferences passed down and check that it is actually respected in the repo's quality assurance process.