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