[gsoc] DUB - Ideas

[Atila Neves]

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.
>
> Hence, I will try to introduce this new [gsoc] series aimed at 
> (1) discussing potential ideas in depth and (2) maybe finding 
> new ideas. I encourage everyone (students or just curious D 
> enthusiasts) to start more of these [gsoc] threads, s.t. our 
> potential students can learn more about the proposed projects 
> (students: please don't be shy).
>
> The first item on my list is D's package manager DUB.
>
> My personal favorite "missing feature" in DUB is a direct git 
> support. It would be really awesome if we would implement a 
> "GitRegistry" for packages, s.t. one can directly depend on git 
> repositories:
>
> dependency "my-package" version="git://.../my-branch#my-commit"
>
> There's also a DEP about this feature [2] (though the proposed 
> format there isn't set in stone). DUB's architecture is already 
> fairly modular, so as a start students could look into creating 
> a GitRegistry supplier [3]. There's also some previous work [4] 
> which can of course be used for inspiration too. While 
> initially, the `git` CLI binary can be used, it's not 
> guaranteed that the user will have this installed (especially 
> on Windows), so one would either need to use e.g. libgit2 (see 
> [5] for a D binding) or implement Git's protocol itself (see 
> e.g. [6]).
>
> @community: what features do you miss the most from DUB?

Some of these might have been done/fixed since the last time I 
ran into them. I wouldn't know because I keep not using dub 
except to make my packages available to everyone else.

1. Bugs getting fixed.

2. Why oh why oh why does it build dependent packages 
serially?????

3. Build per D package by default instead of all-at-once, with 
proper dependency tracking.

4. Ability to use a real build system where needed.

5. `dub describe` actually working, or, even better, an easy to 
use API to query the build. Did you know that the output of `dub 
describe -c unittest` doesn't have the string "-unittest" 
anywhere, much less in "dflags"? Now you do.

6. Not having to write the same code over and over again to check 
if dub dependencies are already downloaded, somehow running 
faster than dub's own checks even if I write said code in Emacs 
Lisp.

7. Ability to avoid the "lib" prefix for libraries on Linux 
(think Python shared objects).

8. Possibility of using a shell other than CMD on Windows 
(preBuildCommands, etc.).

9. Be able to run two dub instances in parallel without crashing 
the linker.

10. A more flexible registry engine so that one can use code that 
lives in a private gitlab instance.


Off the top of my head, that's it.