Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

How to avoid SwiftSyntax annoyance? #793

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
groue opened this issue Oct 13, 2023 · 2 comments
Closed

How to avoid SwiftSyntax annoyance? #793

groue opened this issue Oct 13, 2023 · 2 comments

Comments

@groue
Copy link

groue commented Oct 13, 2023

Hello,

I'm a happy user of Swift Snapshot Testing, and this afternoon I met my first SPM problem due to a conflicting dependency on http://github.com/apple/swift-syntax from another package.

SPM error

Failed to resolve dependencies Dependencies could not be resolved because 'XXX' depends on 'swift-openapi-generator' 0.3.0..<0.4.0 and 'XXX' depends on 'swift-snapshot-testing' 1.14.1..<2.0.0.
'swift-snapshot-testing' is incompatible with 'swift-openapi-generator' because 'swift-openapi-generator' 0.3.0 depends on 'swift-syntax' 508.0.1..<509.0.0 and no versions of 'swift-openapi-generator' match the requirement 0.3.1..<0.4.0.
'swift-snapshot-testing' >= 1.14.1 practically depends on 'swift-syntax' 509.0.0..<510.0.0 because 'swift-snapshot-testing' 1.14.1 depends on 'swift-syntax' 509.0.0..<510.0.0 and no versions of 'swift-snapshot-testing' match the requirement 1.14.2..<2.0.0.

SwiftSyntax is well-known for not following semver, and just create churn in the package ecosystem. Stephen Celis has started the forum thread Macro Adoption Concerns around SwiftSyntax, so I know you're well aware of the problem.

Yes, the landscape may improve over time. For example, maybe SPM will learn to better deal with packages that only depend on swift-syntax for their own tests.

Meanwhile, the dependency of swift-snapshot-testing on swift-syntax is just a ticking bomb waiting to annoy your users when they least expect it.

I'm opening a symmetric issue in the other repository: apple/swift-openapi-generator#329.

@mbrandonw
Copy link
Member

Hi @groue, so the issue in a nutshell is that SnapshotTesting depends on v509 of SwiftSyntax and OpenAPIGenerator depends on v508, making it impossible to depend on both. This is definitely the problem we had in mind when we created that forum post, and when Swift 5.10 is released things are going to get even hairier. But there are a few things that have happened since then that make the situation a little better.

So, a few things come to mind:

  • First of all, OpenAPIGenerator should really consider supporting v509 as soon as possible. There are a ton of people that are going to start depending on SwiftSyntax v509 due to macros, and so only supporting v508 is going to lead to a lot of pain (as you can see). And as far as we can tell, Apple does suggest simply dropping support for old Swift versions as soon as the new one comes out.

  • And second, SwiftSyntax has started to provide some tools that allow one to support multiple versions of Swift. They now provide an empty module for each version of Swift (here's v509's module), and that allows you to do #if canImport(SwiftSyntax509) in order to conditionally support v509. In the near future we will also be able to do #if canImport(SwiftSyntax510), and so on.

    So, theoretically we can relax our dependency on SwiftSyntax to 508...509, and add a bunch of #if canImport(SwiftSyntax509) all over the place to make the code compatible with both versions. I've even started that work here, but there's a lot more to do. If you feel so inclined you could help out with this work, or we can try finishing it when we have time.

In conclusion, barring any fundamental changes from Apple regarding SwiftSyntax, I do think it is going to take significant work for library authors to support multiple SwiftSyntax versions and keep the ecosystem healthy. Only the most dedicated maintainers will do this work, and it's not easy.

@mbrandonw
Copy link
Member

Also this isn't really an issue with the library, per se, so I am going to move this to a discussion.

@pointfreeco pointfreeco locked and limited conversation to collaborators Oct 13, 2023
@mbrandonw mbrandonw converted this issue into discussion #794 Oct 13, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants