DUB - call to arms

[Nick Sabalausky (Abscissa)]

On 4/15/19 7:17 PM, H. S. Teoh wrote:
> On Mon, Apr 15, 2019 at 06:56:24PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> [...]
>> To clarify, I'm mainly referring to the "package manager" aspect of
>> DUB here. I'm less concerned with the "buildsystem" part simply
>> because with a proper package manager, individual projects and even
>> libraries will be free to use whatever buildsystem they want, even if
>> that happens to be "dub build" (which *is* an entirely reasonable
>> choice for many simpler projects...in large part because that's
>> specifically the use-case it was primarily designed for.).
> 
> Y'know, the idea just occurred to me: why even bind the package manager
> to the build system at all?  Why not make the build system one of the
> dependencies of the project?  So you could have library A that is
> written to be built using dub build, and library B that depends on
> 'make', say (where 'make' is some dub-ified description of make as a
> build system), and A depends on B.  So to build A, dub would fetch the
> necessary sources to build 'make', then use 'make' to build B, and then
> build A, and so forth.
> 

Yup, from the sound of it, I think we're on exactly the same page here. 
Basically, a package manager's config should need exactly three things 
from your project:

1. What dependencies.
2. The command(s) to (build, test, etc.)
3. Name(s)/Location(s) of the build's output.

Then, with that information, a package manager provides services such as 
(but not necessarily limited to):

1. A simple, standardized way for you and your users to obtain/build the 
dependencies.

2. A simple, standardized way for buildscripts/buildsystems to obtain 
the information needed to include the dependencies in their own build 
(such as -I... include directories, paths to the now-already-built 
lib/exec binaries, etc.)

 From this, each project can naturally either just roll its own 
buildscripts, or depend on another package providing a builsystem.

Some of the *details* can be quite nontrivial...like dependency 
resolution algorithms, or designing the interactions between package 
manager and buildsystem to be simple, yet effective enough to suit all 
parties needs. But ultimately, it boils down conceptually to be very simple.

I tried to argue in favor of an approach like this earlier on in DUB's 
development, but the author maintained that making a package ecosystem 
all work together requires all packages using the same buildsystem. I 
wasn't able to convince otherwise.