Enable comfortable Swift Package development

[lunij]

With the versions 5.2 and 5.3 of the Swift Package Manager things have changed a lot. Resources are supported now and dev dependencies can also be described in the Package.swift file without the need of third-party packages. We just need to make sure the dev dependencies are not referenced directly by the main product. (see here) Also the generation of an Xcode project beforehand is not necessary anymore because open Package.swift will take care of both, the generation process and opening of the Xcode project.

Thanks to all contributors of Marathon! 🙇
(deprecated since mid 2019)

[orta]

Well, that's all good news to me- if you want to try fix CI, I bet it's updating an Xcode version in the travis yml in a few places ( I'm years out of the loop of the native ecosystem) otherwise me or @f-meloni will give it a shot

Thanks!

[lunij]

I'll have a look into the CI later today or this weekend.

Btw, any objections regarding GitHub Actions?

[orta]

Big preference to using GH Actions instead, but I didn't want to force you to do it :D

[f-meloni]

First of all thank you very much for taking the time to open this PR, in general the repo had some point that are now out of date and needed to be adressed, so thank you.

There are two main points that I want to hightlight.

We don't use Marathon anymore, as you correctly pointed out, but we have our own dependencies resolver https://github.com/danger/swift/tree/master/Sources/DangerDependenciesResolver (that is like Marathon with some additional capabilities)
So while the title was indeed wrong, and the link to Marathon is not needed, who uses Danger without using a Package.swift (mainly who uses it installing it from brew), might benefit from the content on the section.

For swift 5.3 I have one concern, that is that who has a Package supporting an older version of Swift or is using an older Xcode will have some issues on using Danger.
Given the latest swift version release is 5.3.3 a lot of people might be affected by this.

I'm totally fine with using GitHub Actions.

@orta Thoughts?

[lunij]

Thanks for your feedback!

I played a bit with the danger-swift code and now I'm close to understand what is actually going on with the dependency management. As far as I understand, the dependency resolver is needed to identify plugins right before SwiftPM tries to do the actual dependency management, right? That makes totally sense, even though the mysteriously changing Package.resolved makes me want to destroy something. 😅

So while the title was indeed wrong, and the link to Marathon is not needed, who uses Danger without using a Package.swift (mainly who uses it installing it from brew), might benefit from the content on the section.

I do not really get the thoughts behind this sentence. Do you mean they benefit because the descriptions is close to what the DangerDependencyResolver is doing?

For swift 5.3 I have one concern, that is that who has a Package supporting an older version of Swift or is using an older Xcode will have some issues on using Danger.

I'm not sure why someone might want to support an older version of Swift but wants to be up-to-date with tools like danger-swift. In case of an older Swift version, there is still the chance to use an older danger-swift version as well.
The rule of thumb is: If you want to use cutting-edge technologies then be cutting-edge yourself.
I haven't tried it yet but there seem to be the chance to support two different SwiftPM versions, 5.2 and 5.3. Both would improve the dependency management by a lot. The 5.3 one just enables the resources feature in addition. But personally I'd make a hard cut here and continue with 5.3 only.

But to be honest, the dependency management needs a revisit. This is clear to me every time I'm looking at the following screenshot:

danger-swift is a very nice tool, but it is a small tool. A small tool with such an amount of dependencies is a bit irritating. Actually most of the listed dependencies are just sub-dependencies of other dependencies that still rely on pre-5.2 Swift version. Because SwiftPM just resolves all dependencies with versions before 5.2, the list also includes dev dependencies like Quick and Nimble. From 5.2 on SwiftPM would exclude those dependencies.

Speaking about dependencies and SwiftPM versions, your own dependencies like Komondor and Logger would also benefit from such a version change, even though I think the latter could be replaced with swift-log entirely. 🤔

So what do you think?

[f-meloni]

I do not really get the thoughts behind this sentence. Do you mean they benefit because the descriptions is close to what the DangerDependencyResolver is doing?

Yes, the DangerDependencyResolver public interface is equal to what Marathon was offering, to not have breaking changes.

The DangerDependencyResolver downloads the plugins when you are not importing them with in your Package.swift, to offer a version of Danger that is more indipendent from SPM.
You can see an example of its usage at https://github.com/Moya/Moya/blob/master/Dangerfile.swift

I'm not sure why someone might want to support an older version of Swift but wants to be up-to-date with tools like danger-swift. In case of an older Swift version, there is still the chance to use an older danger-swift version as well.

I would like to offer a little bit of flexibility like one - two versions, and not always force everyone to upgrate to the latest xcode to get the latest Danger, there might be a fix they need or something similar.
I know a lot of companies that are still on Xcode 11, and given we still need to use rocket during our release make it comment what is not needed can let us be kind also to who for several reasons didn't update yet.

There is also to consider that many of the open source projects are still supporting from swift 5.1/5.2 and those might want to have the latest Danger in their Package.swift too.
Even famous tools like Swiftlint or Swiftformat keep a little bit of flexibility. (even the mentioned Moya uses Xcode 11 on CI)
While obviously we can not support a lot of swift versions, or we sometimes need to cut support with the old version when a new major version is out, I think we need also to not be strict about supporting only the latest version.

We ditribute Danger via brew, so this upgrade might also be annoying for who gets the new version, I know they can point an older formula, but I would like to minimise the work people has to do to keep danger working in the CI, with keeping at least swift 5.2 support, and maybe dropping it a little bit after swift 5.4 is out.

danger-swift is a very nice tool, but it is a small tool. A small tool with such an amount of dependencies is a bit irritating. Actually most of the listed dependencies are just sub-dependencies of other dependencies that still rely on pre-5.2 Swift version. Because SwiftPM just resolves all dependencies with versions before 5.2, the list also includes dev dependencies like Quick and Nimble. From 5.2 on SwiftPM would exclude those dependencies.

We decided to use SPM to handle all the tools we needed for development (but are removed to avoid everyone else to have to download them too), so the dependencies you have there are to lint, format, document the code etc.
I think is nice to have one single place to download everything, if it wasn't the case, there would have been a bootstrap script or something like that for development, while now it "just works", you just need to install Komondor.

I'm open to make some improvements like using swift-log though, even if it doesn't actually improve the dependency graph (is even bigger than Logger), is nice to use something that Apple maintains for us, and is a lot more likely that that is already a dependency of someone's Package.swift, avoiding SPM to have to download two logging tools.

[orta]

Aye, I don't have much to add which hasn't been said already but just adding I think our dependency tree is a reasonable size - it's when dev deps are included in other people's apps that things become unreasonable

[f-meloni]

Hey @lunij, now that we managed to get macOS 11 in our CI, I think we can get this PR in, can you please merge master back in the PR to see if there are other dependencies that can be updated and if it still passes CI?

Thank you :)