gradle-native icon indicating copy to clipboard operation
gradle-native copied to clipboard

Consume Swift Package Manager Dependencies

Open eljobe opened this issue 7 years ago • 7 comments

The Swift Package Manager (PM) is the most widely-used way of building Swift projects currently. It is basically a build system with a lot of assumptions built in. Since we don't want to require projects to first migrate all of their dependencies to from Swift PM to Gradle before trying to convert the project itself, we must be able to consume Swift Package Manger projects as dependencies for a Swift Gradle project.

eljobe avatar Jul 18 '17 14:07 eljobe

I think the title of this epic could do with some refinement.

There are several broad use cases here:

  1. When I build a Swift component using Gradle I can consume a version of a Swift library released by a team that uses Swift PM. This means I don't have to wait for all of my dependencies to migrate before I start using Gradle.
  2. When I release a version of a Swift library using Gradle, other teams that use Swift PM to build a Swift component can consume this new version. This means I don't have to wait for all of my consumers to migrate before I start using Gradle.
  3. Gradle assists me to migrate an existing component that is built using Swift PM so it can be built with Gradle instead.

There's a related use case that may (or may not) reuse the implementation of use case 2: When I release a version of a Swift library using Gradle, other teams that use Gradle to build a Swift component can consume this new version.

adammurdoch avatar Jul 24 '17 08:07 adammurdoch

@adammurdoch, I'm skeptical that we need to support use case 3. from your list.

Do you have a specific suggestion for a "refined" title for this epic? I assume you are suggesting something which explicitly expresses the different types of integrations we are rolling up into this Epic.

How about: Publish and Consume Swift Package Manager Projects

eljobe avatar Jul 24 '17 08:07 eljobe

I'm skeptical that we need to support use case 3. from your list.

Of course we do. But it's much less important than the other 2 and is something we can do later.

For the title we need to decide whether this epic represents the features that allow an organisation to migrate a bunch of software from Swift PM to Gradle in an incremental way, or whether this epic represents the features that allow an organisation to share Swift libraries between teams (whether they are using Gradle or Swift PM).

adammurdoch avatar Jul 24 '17 20:07 adammurdoch

I was thinking that the scope of this epic would be to cover both of those sets of features.

eljobe avatar Jul 26 '17 13:07 eljobe

It might be better to split this into 2 epics, one for publishing/sharing and one for migration. They may happen to overlap quite a bit in implementation, but they are quite different use cases and have different priorities.

adammurdoch avatar Jul 26 '17 19:07 adammurdoch

Changed the Title and Description of this Epic to cover use case 1. Added #48 to cover use case 2. Moved #40 from this epic to the other one.

eljobe avatar Jul 26 '17 21:07 eljobe

I recently found out about Gradle support for Swift projects and in my effort to figure out how to consume third-party Swift projects...I ran into this issue. I wanted to see if this is still on anyone's radar? It seems pretty imperative if Gradle aims to get any traction in this particular space. I'd be willing to dedicate development effort into it myself if its low priority for the core team of maintainers. I love using Gradle when I'm writing code targeting the JVM and I'd like to be able to use it for my Swift projects as well. Unfortunately, without a solid developer story for consuming third party Swift libraries I can't see myself using it anytime soon for anything serious.

Steven0351 avatar Feb 18 '20 06:02 Steven0351