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.

On Friday, 1 March 2019 at 14:16:17 UTC, Atila Neves wrote:
> 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.

That is actually to some extent expected behaviour. -c unittest only refers to the unittest configuration, not the unittest *build*.

dub describe -c unittest -b unittest

will give you "unittests" under targets[0].buildSettings.options

Of course those options still need to be converted in to the relevant compiler flags.

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.
>
> [...]

- Cross compiling support https://github.com/dlang/dub/issues/1523
- Usable with private repos https://github.com/dlang/dub/issues/1499

On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:

> @community: what features do you miss the most from DUB?

A properly working preGenerateCommands https://github.com/dlang/dub/issues/1474

- Bastiaan.

On Friday, 1 March 2019 at 14:28:54 UTC, John Colvin wrote:
> On Friday, 1 March 2019 at 14:16:17 UTC, Atila Neves wrote:
>> 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.
>
> That is actually to some extent expected behaviour. -c unittest only refers to the unittest configuration, not the unittest *build*.
>
> dub describe -c unittest -b unittest
>
> will give you "unittests" under targets[0].buildSettings.options
>
> Of course those options still need to be converted in to the relevant compiler flags.

Bad example from me. Replace "-unittest" with "-g -debug" for the debug build, which is the default.

Why anyone would want to use the "unittest" configuration (which is treated differently by dub) in a non-unittest build is beyond me.

On Friday, 1 March 2019 at 09:41:55 UTC, Guillaume Piolat wrote:
> - colors, with way easier error messages! DUB IS THE PRIMARY INTERFACE TO D.

For ref, there was this initiative by gdelazzari in June.
https://forum.dlang.org/post/vefplpvwvrcbednsufli@forum.dlang.org

On Friday, 1 March 2019 at 10:24:45 UTC, Mike Parker wrote:
> I'll stake my flag on that hill! Remove JSON if anything :-) It's ugly, it's noisy, and it doesn't allow comments. SDLang is much cleaner and human-friendly.

Let's disagree!
- JSON schemas
- lots of parsers, you can parse it at compile-time
- it's well known
- the "best language" for 20 lines recipe files has very little upside

On Friday, 1 March 2019 at 16:21:19 UTC, Guillaume Piolat wrote:
> On Friday, 1 March 2019 at 10:24:45 UTC, Mike Parker wrote:
>> I'll stake my flag on that hill! Remove JSON if anything :-) It's ugly, it's noisy, and it doesn't allow comments. SDLang is much cleaner and human-friendly.
>
> Let's disagree!
> - JSON schemas
> - lots of parsers, you can parse it at compile-time
> - it's well known
> - the "best language" for 20 lines recipe files has very little upside

It's obvious no one will win the SDL vs JSON debate. The only solution is to dump both and switch to YAML :)

On Friday, 1 March 2019 at 17:22:47 UTC, JN wrote:
> It's obvious no one will win the SDL vs JSON debate. The only solution is to dump both and switch to YAML :)

Believe it or not, there is a proposal for a third format (the 'tree' format).
https://github.com/dlang/dub/wiki/DEP7

* Obligatory reference to https://xkcd.com/927/ *

I wish one of the two got dropped. I'm using SDL now since it's officially recommended, but I'd prefer to only keep JSON since it is a clear format that newcomers don't need to familiarize with, while SDL (still) to me looks like a bunch of tags floating around without clear structure.

Keeping only SDL is fine to me too, it's better than having two competing standards.

On 2019-03-01 17:22, Digitalmars-d wrote:
> On Friday, 1 March 2019 at 16:21:19 UTC, Guillaume Piolat wrote:
>> On Friday, 1 March 2019 at 10:24:45 UTC, Mike Parker wrote:
>>> I'll stake my flag on that hill! Remove JSON if anything :-) It's ugly, it's noisy, and it doesn't allow comments. SDLang is much cleaner and human-friendly.
>> 
>> Let's disagree!
>> - JSON schemas
>> - lots of parsers, you can parse it at compile-time
>> - it's well known
>> - the "best language" for 20 lines recipe files has very little upside
> 
> It's obvious no one will win the SDL vs JSON debate. The only solution is to dump both and switch to YAML :)

or to keep bicycle-shedding: TOML
- (even) "nicer" than SDL
-  more sane than YAML
(one thing Rust perhaps got better)

https://forum.dlang.org/search?q=toml&scope=group%3AdigitalmarsD