[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