Make sourcePaths work as documented

[omerfirmak]

sourcePaths is only default initialized when both
top level and configuration level sourcePaths is empty.

Fixes #1913

[dlang-bot]

Thanks for your pull request and interest in making D better, @omerfirmak! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

[omerfirmak]

Apparently, some projects in buildkite relied on the old behavior.

[Geod24]

Apparently, some projects in buildkite relied on the old behavior.

Probably most people that use this will implicitly depend on this behavior.
@atilaneves what do you make of this change / issue ?

[atilaneves]

I think that, unfortunately, breaking projects that relied on the old behaviour is a no-no. As I mentioned in the issue itself, putting both apps in, say, foo/app1 and foo/app2 instead of in a top-level source directory seems to sidestep this issue.

[Geod24]

I think that, unfortunately, breaking projects that relied on the old behaviour is a no-no.

Yeah, that's a given.

As I mentioned in the issue itself, putting both apps in, say, foo/app1 and foo/app2 instead of in a top-level source directory seems to sidestep this issue.

The question was more about whether you considered it a valid issue as well, being a user of the current behavior.
Just so there isn't one single person (me) providing feedback. If that's something you agree on, then we can talk about deprecating this behavior, by asking people to add source in their configurations as well.

[atilaneves]

If it didn't break any projects I'd say ok, but it does, so...

[rikkimax]

There are enough issues with dub doing things that people don't expect that this should be fixed.

But @atilaneves is right, it could break projects.

So how about a big honking warning (for projects it will break) for a couple of years and not make it go live until then?

[PetarKirov]

I guess the simplest way to resolve matters like this is by adding a settings.json option to revert to the old behavior that would be available for a deprecation period of 2 years and could be enabled by default for next 3 releases or something like that.

[s-ludwig]

I guess the simplest way to resolve matters like this is by adding a settings.json option to revert to the old behavior that would be available for a deprecation period of 2 years and could be enabled by default for next 3 releases or something like that.

A global setting won't cut it, as it may need to be set in some packages, but must not be set in others. But adding a deprecation warning (along with mitigation instructions) would be a good idea in any case. We could also add that setting to the package recipe to allow silencing the warning by forcing the new behavior.