Hi all,

The problem
-----------

I think this is well-known, but I still highly encourage you all to have a look at this thread:

https://forum.dlang.org/thread/eftttpylxanvxjhoigqu@forum.dlang.org?page=1

or the issue tracker:

https://github.com/dlang/dub/issues

tl;dr: the status quo of dub is really really terrible:

- tons of issues (often unanswered)
- __critical__ piece of infrastructure
- less than a PR per month

I had to use Cargo the other day and compiling 80 (!) dependencies was a
miracle (parallel fetching and builds).

We want the D ecosystem to grow and flourish and I don't think I have to
stress how important a good package manager is for this.

What can we do?
---------------

We have about $6k in our OpenCollective budget [1] (there's still the
$3k that we owe WebFreak) which means we have about $3k left.
I propose to use this as a starting base to fund serious work
on Dub (see the forum thread for a few ideas).

I believe that with the D community pitching in and a few companies
(they complain about dub too), we could get about $10k for this effort.

Now, of course, the question is what can we do to improve Dub's status quo?

It would be amazing if we could hire Martin or Sönke (even if it's only
part-time), but unfortunately as far as I am aware that's not an option
as both are pretty busy these days.

[1] https://opencollective.com/dlang/

Proposed actionable
-------------------

Hence, here's my proposal:

Publish a blog post analog to this "Calls to arms for Dub". The post could

- summarize the reasons why funding dub is so crucial
- what the biggest problems of dub are (i.e. the issues that we would
target first)
- announce that we start a new funding round (with $3k already seeded
from OC)
- maybe some companies are willing to pitch in too (e.g. Symmetry, Funkwerk, Sociomantic, ...)
- put out a call open for anyone to apply for this project

The exact details on payment and expectations would need to be specified, but I guess we should be able to fund roughly three months of work. OTOH we can leave these details open to the applicants as students might be willing to work for $10k for three months, but experienced software engineers might not. Also, some people probably could only afford to work part-time on these which imho would be fine too.

@community:

1) Would this be sth. you would consider applying in general? If not what could we do to improve this?
2) Would this be sth. you would consider donating to?


For completeness, my personal favorite items for this would be sth. like:

- parallel dependency downloads and builds (dub could and should be a lot faster)
- option to emit only include flags (for good integration in other tools)
- "dub install"
- dub watch (there's a PR that needs to be revived - https://github.com/dlang/dub/pull/446)
- colored error messages (there's already a PR that just needs to be revived - https://github.com/dlang/dub/pull/1490)
- cached dub registry index

Though I think if we crowd-fund this campaign, we should make a list of the top 20-30 issues and then let everyone vote on them.

On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
> 1) Would this be sth. you would consider applying in general? If not what could we do to improve this?

If think DUB is completely _unsound_ and need a rewrite from someone versed in compilers and correctness.



> 2) Would this be sth. you would consider donating to?

Only if it's a rewrite.

On Sunday, 14 April 2019 at 10:59:29 UTC, Guillaume Piolat wrote:
> On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
>> 1) Would this be sth. you would consider applying in general? If not what could we do to improve this?
>
> If think DUB is completely _unsound_ and need a rewrite from someone versed in compilers and correctness.
>
>
>
>> 2) Would this be sth. you would consider donating to?
>
> Only if it's a rewrite.

Dub has a working eco system and a lot of developers put effort into it. It will take years to have another solution with the same functionality like Dub and please do not forget we still have to maintain Dub until the new solution can replace Dub.
Could you please write the details why a correction of Dub isn't possible and a complete rewrite is the only solution?

Kind regards
Andre

On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
> Hi all,
>
> The problem
> -----------

Hey guys, maybe this is an offtopic (which could sound heretical btw), but didn't you ever think about writing a package manager using some scripting languages like Python or JavaScript?

The package manager is an infrastructure thing, so it not so critical as the rest of other tools.

Maybe, a consideration of this idea would help to attract more people from the outside of the community, because there is a feeling that we're pretty much locked on the community itself.

On Sunday, 14 April 2019 at 11:27:18 UTC, Jacob Shtokolov wrote:
> On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
>> Hi all,
>>
>> The problem
>> -----------
>
> Hey guys, maybe this is an offtopic (which could sound heretical btw), but didn't you ever think about writing a package manager using some scripting languages like Python or JavaScript?
>
> The package manager is an infrastructure thing, so it not so critical as the rest of other tools.
>
> Maybe, a consideration of this idea would help to attract more people from the outside of the community, because there is a feeling that we're pretty much locked on the community itself.

In addition to the Dub executable, you can also use Dub as Library in your D coding. This will not longer be possible, or only   with a lot more effort.

Several developers have put a lot of effort to make DMD independent from the Microsoft build tools / visual studio.
If we now add a new dependency to Python or NPM, that would be really strange)

Kind regards
Andre

On Sunday, 14 April 2019 at 11:21:09 UTC, Andre Pany wrote:
>
> Dub has a working eco system and a lot of developers put effort into it. It will take years to have another solution with the same functionality like Dub and please do not forget we still have to maintain Dub until the new solution can replace Dub.
> Could you please write the details why a correction of Dub isn't possible and a complete rewrite is the only solution?
>

Don't mistake me, DUB is a good software that is very useful and that's a feat for a build system - something very easy to hate.

A lot of things are possible incrementally, but I believe in the DUB design some things will not be possible.

- dub.selections.json is supposed to encode dependency resolution, but fundamentally it does that for a particular optional dependencies selections set and configuration.

- I personally think it has way to many features, and in such situations it's way harder to find those to remove because agreement is difficult

- work is piling on for DUB because it is designed in a way that say yes to everything, features have piled on with no regards for who would maintain them

Withing DUB there is a much simpler subset to be discovered I believe. For the record I was an early contributor, I did what I could.

On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
> Hi all,
>
> The problem
> -----------
>
> [...]

I fully agree.

Also somehow off topic but we should not only think about how to solve coding problems but also how to attract new developers which in the end increases the community and will also help us to solve issues and build enhancements and in the end will also attract other developers.

Maybe we should invest some money into marketing. Also another idea is to setup a campaing, for 2 weeks all community members concentrate not on development but on advertising D in some form.

Maybe we can also donate some exemplares of Ali's book to students in universities.

There are so much possibilities to increase the visibility of D.

Kind regards
Andre

On Sunday, 14 April 2019 at 11:27:18 UTC, Jacob Shtokolov wrote:
> On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
>> Hi all,
>>
>> The problem
>> -----------
>
> Hey guys, maybe this is an offtopic (which could sound heretical btw), but didn't you ever think about writing a package manager using some scripting languages like Python or JavaScript?
>
> The package manager is an infrastructure thing, so it not so critical as the rest of other tools.
>
> Maybe, a consideration of this idea would help to attract more people from the outside of the community, because there is a feeling that we're pretty much locked on the community itself.

We are too small a community so can you please do this for us? Not a good argument.

On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
> 1) Would this be sth. you would consider applying in general? If not what could we do to improve this?
> 2) Would this be sth. you would consider donating to?

No and no. Dub delivers negative value for my use-case; it is a cost to me to maintain these definition files for other people (and it is a support pain too, which people dropping in having dub problems that don't exist in the underlying compiler), even though I don't use it.

I don't use it because it offers nothing of value to me; it solves a problem I don't even have (and does so in a way that is mostly incompatible with my existing code). It is all negative with nothing in the positive column to balance it out.


I'd say we split dub up into three concerns:

1) code.dlang.org. I do see some value in this, and think it is salvageable in its current form.

2) dub, the package manager. Maybe useful, though I don't personally believe in dependencies, I can see some value, though I'd want to change it so it has more compatibility with other workflows (like mine) and be sure to limit its scope to developer use-cases; end users should never know.

3) dub, the build tool. I'd rather have it either do absolutely nothing here, or just delegate to something else.


I gotta run, might write more later.

On Sunday, 14 April 2019 at 11:38:23 UTC, Guillaume Piolat wrote:
> Withing DUB there is a much simpler subset to be discovered I believe.

With that said, I think I have been unreasonable, would contribute to an incremental effort too.

Dub probably just lacks a tutorial.