[gsoc] DUB - Ideas

[Seb]

On Sunday, 17 March 2019 at 13:54:54 UTC, Joseph Rushton Wakeling 
wrote:
> On Thursday, 7 March 2019 at 16:01:18 UTC, Atila Neves wrote:
>> A fair point.
>>
>> At the time I was trying to pin the pyd version because there 
>> was a bug in the dub registry that prevented me from doing so 
>> in the regular fashion. Then the bug got fixed and I moved on.
>
> It wasn't meant as a personal attack!  Sorry if it came over 
> that way.
>
> I get the motivation, but it feels somewhat dodgy to allow 
> packages in the DUB repository to depend on arbitrary git 
> forks.  What might make more sense is to allow a way for the 
> build call (or settings in `dub.selections.json`) to easily 
> override dependency locations, which can be used for temporary 
> workaround like this.  What do you think?

The dub.selections.json isn't used for dependencies.
All major package managers have built-in VCS support for a good 
reason:

https://pip.pypa.io/en/stable/reference/pip_install/#vcs-support
https://docs.npmjs.com/files/package.json#git-urls-as-dependencies
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
https://golang.github.io/dep/docs/ensure-mechanics.html
...

Especially in the D ecosystem there are a ton of good, 
unmaintained projects which just require a small change to work 
with e.g. latest DMD and you can't get that into "upstream", 
because the author isn't there anymore or very inactive.
I understand that in a perfect world we wouldn't have to do this, 
but in practice this is a lot better than registering dummy fork 
packages on the Dub registry every time.

An example to what the current limitation leads to:

https://github.com/dlang-tour/core/pull/487