Linux support not ok for swiftformat

[doozMen]

The build binary of swiftformat at url https://github.com/calda/SwiftFormat/releases/ has support only for apple platforms

{
  "schemaVersion": "1.0",
  "artifacts": {
    "swiftformat": {
      "version": "0.50-beta-4",
      "source": "https://github.com/calda/SwiftFormat/releases/tag/0.50-beta-4",
      "type": "executable",
      "variants": [
        {
          "path": "swiftformat",
          "supportedTriples": ["x86_64-apple-macosx", "arm64-apple-macosx"]
        }
      ]
    }
  }
}

Hence running the format tool on linux does not work but the Readme states it is compatible with linux, but unfortunately it is not.

[calda]

the Readme states it is compatible with linux

This may be a bug in the Swift Package Index compatibility detection. I think that badge previously only said that the package supported macOS, but now (incorrectly) says it supports Linux. Would you be interested in filing a bug report on the Swift Package Index repo about this?

Regarding actually supporting Linux for this tool -- I can look in to this next time I update the SwiftFormat binary that we use.

[finestructure]

This may be a bug in the Swift Package Index compatibility detection

Yes, this is a problem with our compatibility detection for plugins. We're building the plugin and that just works™ on Linux 😅

As I mentioned in the issue, I'm not sure how to best fix this on our end. It'd certainly take a while to sort out. In the meantime, a quick (and rather ugly) fix would be to break the Linux build intentionally by inserting

#if os(Linux)
#error("Linux is currently not supported")
#endif

somewhere in the source (or even the Package.swift manifest). Would that work for you?

[calda]

good idea, thanks for the suggestion!

[calda]

@finestructure, I made this change in #206 but it seems to have broken our package's pack on Swift Package Index: https://swiftpackageindex.com/airbnb/swift

[calda]

Here's a bug report for that issue: SwiftPackageIndex/SwiftPackageIndex-Server#2117

[finestructure]

As fas as I can see everything is working as expected - see my comment over in the issue! Not sure what went wrong there but it seems to be ok now :)

[doozMen]

I fixed this issue for now for us by depending not on the binary of swiftformat but on the release. https://github.com/doozMen/swift/releases/tag/1.0.2 points to https://github.com/calda/SwiftFormat/releases/tag/0.51-beta-3. This is a workaround as now our ci pipeline is slower but at least it can run on linux ...

[calda]

Good idea, we could use #if os(Linux) to build SwiftFormat from source instead of using the binary dependency.

How did you handle SwiftLint? That binary dependency also appears to only support macOS.

[doozMen]

I made manual builds now for linux and updated the swiftformat and swiftlint bundle artifact. Bot on my machine with aarch64-linux-gnu, arm64-apple-darwin22.1.0 and our pipeline running with docker aarch64-linux-gnu and ubuntu 18 this now works.

https://github.com/doozMen/swift/releases/tag/1.0.6

The problem is that I did not automate the building process of the artefact bundle. I would need some help with that as you would need to make builds on 3 machines with the above architecture. In essence the problem with both swiftlint and swiftformat binaries is that they are build for linux with fat binaries that do not work on arm64 as explained https://www.polpiella.dev/binary-targets-in-modern-swift-packages#fat-binaries-and-frameworks. I hope both swiftformat and swiftlint would include in there future releases an artifactbundle like the above and include the checksum needed.

[doozMen]

Good idea, we could use #if os(Linux) to build SwiftFormat from source instead of using the binary dependency.

How did you handle SwiftLint? That binary dependency also appears to only support macOS.

I Also build swiftlint from source. But it is also possible to add multiple target triples to the artefactbundle info.plist like I did in my comment. That way it works on Linux with a binary target. Just requires building on 3 machines.
That last step I have not automated unfortunately