DUB - call to arms

[Atila Neves]

On Monday, 15 April 2019 at 19:52:10 UTC, Guillaume Piolat wrote:
> On Monday, 15 April 2019 at 16:37:38 UTC, Nick Sabalausky 
> (Abscissa) wrote:
>> I've personally put a lot of effort into trying to fix DUB's 
>> problems in the past. Though I would be happy to be proven 
>> wrong, at this point, I'm all but convinced the problems with 
>> DUB are far too fundamental.
>>
>> I know this is the sort of proposal that makes people cringe, 
>> and often for good reason, but in this case, I really do think 
>> it would be quicker, easier, and produce a better result to 
>> simply re-design it from the ground up (while making sure to 
>> leverage the existing code.dlang.org ecosystem in some say), 
>> than to try to wrangle this 600lb gorilla into something it 
>> was never designed to be.
>>
>> I've long been hoping to take a stab at this myself, and I 
>> often find myself thinking through details of how it would 
>> work. I would, however, need help with the 
>> dependency-resolution algorithm (perhaps somebody could go 
>> into DUB and work to decouple its dep resolution algoritms 
>> from the rest DUB as much as possible - or at least document 
>> how to interface with it as a lib).
>
> I've tried paying MrSmith33 to write a DUB replacement for a 
> while.
> I think the "incremental" camp is 80% right saying that a DUB 
> rewrite is a pipe dream in large parts.
>
> However if you want to build on that small attempt, don't 
> hesitate to pick what you like: 
> https://gitlab.com/AuburnSounds/rub (coined "idub" for a pun)

I'll take a look. In the meanwhile I started this:

https://github.com/kaleidicassociates/bud

It uses dub as a library to make sure that it works just as dub 
does, but bypasses what it can. The idea is to completely 
separate these disparate tasks:

* Dependency version resolution (from dub.{sdl,json} -> 
dub.selections.json)
* Fetching dependencies that are not already in the file system 
(trivial after dub.selections.json has been generated)
* Extracting information from dub about source files, import 
paths, etc.
* Actually using the information from dub to build

In the future dub.selections.json will have to be fixed to have 
different entries per configuration, and possibly per platform as 
well. Fortunately there's a version field in the current format. 
I'm currently concentrating on assuming that dub.selections.json 
is generated and taking it from there.