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?

It's obviously not great if e.g. one has a library package that triggers a bug in one of its dependencies and has no possibility of an in-code workaround, but it seems more secure and consistent to require dependency overrides to be chosen by the user rather than allowed in any circumstances.

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?
>
> It's obviously not great if e.g. one has a library package that triggers a bug in one of its dependencies and has no possibility of an in-code workaround, but it seems more secure and consistent to require dependency overrides to be chosen by the user rather than allowed in any circumstances.

One can already override locations in dub.selections.json, the problem there is automating it so downstream users don't have to do anything.

The whole thing was just a workaround for a dub registry bug that got fixed anyway, so I don't think it's too important going forward.

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

On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:
> So while we have quite a large list of potential GSoC projects [1], I think that many of these ideas are still a bit too abstract for potential students.
>
> [...]


Support staged build and install for ease packaging process.
Usually build tools support staged install by using the special environment variable DESTDIR. It is a coding standard: https://www.gnu.org/prep/standards/html_node/DESTDIR.html

Be able to run dub on offline computer and looking dependencies following this order: (i) /usr/{lib,include,bin}, (ii) /usr/local/{lib,include,bin}, (iii) /${HOME}/.local/{lib,include,bin}