DUB - call to arms

[Nick Sabalausky (Abscissa)]

On 4/16/19 1:39 PM, H. S. Teoh wrote:
> On Mon, Apr 15, 2019 at 07:52:07PM -0400, Nick Sabalausky (Abscissa) >>
>> 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.)
> 
> I'd add:
> 
> 3. A standard query interface for querying a remote repository for
> packages (matching some names / patterns) and version numbers.
> 

Oh, don't get me wrong, there's a whole BUNCH of things I'd like to see 
on this particular list, and that definitely includes your suggestion. I 
left it at "not necessarily limited to..." for good reason ;)


>>  From this, each project can naturally either just roll its own
>> buildscripts, or depend on another package providing a builsystem.
> 
> That's a good idea.  Completely decouple package management from
> building.  Let the package manager do what it does best: managing
> packages, and leave the compilation to another tool more suited for the
> job.

Exactly.

> I was thinking the build/test/etc. command can itself be defined by a
> dependency.  For example, if your project uses make for builds, there
> could be a `make` dub package that defines command-line templates used
> for generating platform-specific build commands. Your package would
> simply specify:
> 
> 	"build-system": "make"
> 
> and the "make" package would define the exact command(s) for invoking
> make [...etc...]

Interesting idea. I definitely like it, though I would consider it not a 
"basic fundamental" mechanism, but rather a really nice bonus feature 
that provides a convenient shortcut for having to specifying certain 
things manually...IF you happen to be using a buildsystem known by the 
package manager...or (better yet, if possible) a buildsystem that's able 
to tell the package manager enough about itself to make this happen.


>> 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.
> [...]
> 
> If done correctly, dependency resolution is just a topological walk on a
> DAG.  Get this right, and everything else falls into place.

Yes, but therin lies the rub - "getting this right". AFAICT, Sonke seems 
to have a very good grasp on dependency resolution via DAG (or at least, 
certainly a far better grasp than I do). But yet, even his algorithms in 
DUB, he needed to occasionally patch with common-use-case 
short-circuiting logic (and I don't even know what else) just to fix 
various seemingly-infinite-loop issues (not technically infinite, but 
appeared to be to the user) that people were still reporting some years 
into DUBs lifetime.

'Course, if it really is simpler than it seems to me (and *especially* 
is it *isn't*), then I'd certainly be more than happy to delegate 
dependency resolution out to somebody else.