dud: A dub replacement

Robert Schadek rschadek at symmetryinvestments.com
Tue Nov 19 08:29:06 UTC 2019


On Monday, 18 November 2019 at 16:31:09 UTC, Nick Sabalausky 
(Abscissa) wrote:
> On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:
>>        - I would imagine getting dependency resolution really 
>> right
>>          would be top of the list -- it would be good to aim 
>> to fix
>>          issues like https://github.com/dlang/dub/issues/1732
>
> As has been discussed elsewhere a few months ago, dependency 
> resolution should be outsourced to an established SAT 
> <https://en.wikipedia.org/wiki/Boolean_satisfiability_problem> 
> solving lib, to avoid re-inventing a notoriously difficult 
> wheel. This is what all the serious package managers have been 
> moving towards, after invariably hitting problems (much like 
> dub) trying to roll-their-own.

OT: By saying "all the __serious__" you effectively ended this 
part of the thread.
You basically say, that whatever I do, solve P=NP for instance, 
dud will
never be a __serious__ package manager because it does not use an
existing SAT solver.
That's just bad arguing.

The thing I want from dud, is to tell me what dependency chain 
let to conflicts
and this I find hard to extract from current SAT solvers.
Most I have worked with just told me: "This solution works" "NO"
Also the debug experience is not really great most of the time.
And I like a good debug experience.

I'm not saying I will or want to reinvent the wheel on dependency 
resolution,
but if there is a choice of Understandability + debugability vs. 
performance.
Performance will suffer.




More information about the Digitalmars-d-announce mailing list