[gsoc] DUB - Ideas

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Mon Mar 4 14:45:00 UTC 2019


On Monday, 4 March 2019 at 14:04:41 UTC, Seb wrote:
> You fix a bug in let's say Vibe.d (or any other library for 
> that matter). You don't want to wait 6 months until your bug 
> fix gets merged and released (if ever). I have run into this 
> many many times.

Perfectly reasonable use-case, the question is whether the right 
solution is to tie DUB to direct support for git submodules.

I'll slightly rephrase my earlier remarks: this and other cases I 
can think of all seem to come down to:

     How does one make DUB aware of and able to handle a codebase 
that
     is not registered in the main DUB package repo and possibly 
does
     not even define its own DUB package config?

What I would suggest is that rather than building in direct 
support for git, which is only one VCS, we consider instead how 
to make it possible to specify dependencies in terms of two kinds 
of instructions:

   * how to fetch a dependency's code and place it in a directory 
determined
     either by DUB itself or by another setting in the `dub.json` 
file

     - this might be done by a git clone or checkout, or by 
fetching and
       unzipping an archive file, or by a number of other options

   * how to define DUB packaging/dependency settings if the 
dependency does
     not define them in its own codebase

That should be a more flexible approach that would allow the same 
outcomes.


More information about the Digitalmars-d mailing list