Incorrect package data for groue/GRDB.swift

[groue]

Which package(s) are showing incorrect data?

• https://swiftpackageindex.com/groue/GRDB.swift

Please explain what data is incorrect and what you expected to see

The page is telling that the package does not build on iOS, tvOS and watchOS. This is inexact.

If the problem relates to the compatibility matrix, does it apply to specific builds?

Please find the builds exhibiting the problem from the "Full Package Compatibility Report" menu item in the side menu and link the build reports here.

• iOS: https://swiftpackageindex.com/builds/BC152750-3F44-403D-9956-525212C18259
• tvOS: https://swiftpackageindex.com/builds/E02F2CF8-BD7A-496D-8E8C-DA5E0CCCCA7C
• watchOS: https://swiftpackageindex.com/builds/80ED36DD-EA03-477A-86BA-C30740F74BD4

Where possible, try and replicate the problem you have found by running the "Build Command" at the top of a build report. This command is what our build servers execute.

It looks like the "Build Command" does not support packages that contain two Xcode projects.

[finestructure]

Thanks for the report, @groue !

You're right, two Xcode projects isn't a configuration we support.

I've just tried and the package builds correctly if I move GRDBCustom.xcodeproj into a subfolder. Is that a decent workaround?

[groue]

Hello @finestructure,

I've just tried and the package builds correctly if I move GRDBCustom.xcodeproj into a subfolder. Is that a decent workaround?

To be honest, I'm not thrilled.

If SwiftPackageIndex requires library authors to adopt some ad-hoc convention (such as a specific file-system organization, as you suggest), then what if the library author wants to support another tool that requires another convention? Conflicts arise, and its impossible to give a chance to both SwiftPackageIndex and the other tool.

Another reason that prevents me from moving the GRDBCustom.xcodeproj project is that this would break the builds of users who use it.

I already had a very unpleasant and similar experience with the Carthage package manager, and the final decision was simply to give up.

That's a pity, because there was a much better possible outcome.

When a project does not follow a convention, because reasons ¹, convention is not enough. What is needed is configuration.

That's why I would rather suggest defining a configuration file SwiftPackageIndexFile, or .swiftpackageindex, or .swiftpm/swiftpackageindex, etc. When a package is not well handled by SwiftPackageIndex because the package does not follow the expected convention, the library author can still opt in for a quality output by adding this file to his project, and feed your rendering engine with the required information.

That would be a much better UX than requiring changes in the files organization (with indirect consequences such as file reference updates, documentation updates, test updates, major version bump, etc.)

Footnotes

1. GRDB is a plain SPM package, plus a CocoaPods, plus an Xcode project that links against the system SQLite, plus an Xcode project that links against custom SQLite builds, plus demo apps... Users have a lot of installation options and all of them are in the scope of semantic versioning. ↩

[daveverwer]

Thanks for the reply @groue

If SwiftPackageIndex requires library authors to adopt some ad-hoc convention (such as a specific file-system organization, as you suggest), then what if the library author wants to support another tool that requires another convention? Conflicts arise, and its impossible to give a chance to both SwiftPackageIndex and the other tool.

Of course, and I @finestructure suggested that as it may have been a quick way to work around this issue.

We want the package index to be seen as a benefit to both people searching for packages and package authors alike. We don’t want to place unreasonable requirements on package authors, but the complexities of trying to build 5,000 open-source packages are significant and new edge cases such as this pop up all the time.

We appreciate the time and effort that all package authors put into their work and we want to show them off in the very best way. The quickest way to get the package compatibility showing correctly would have been to remove/move one of the project files, but it’s not the only way.

That's why I would rather suggest defining a configuration file SwiftPackageIndexFile, or .swiftpackageindex, or .swiftpm/swiftpackageindex, etc. When a package is not well handled by SwiftPackageIndex because the package does not follow the expected convention, the library author can still opt in for a quality output by adding this file to his project, and feed your rendering engine with the required information.

Exactly, and we have dealt with all of the edge cases that have come up in this way with the configuration file that we already have. The same one we talked about when we chatted about opting in to documentation generation, the .spi.yml file.

We don’t currently have a way to work around packages with multiple Xcode projects like this, but I just had a quick play with our build tool and it appears like it would be possible to resolve if we use the .spi.yml file to take a per-platform --project parameter that we can pass into xcodebuild.

For example, this command builds your project without errors:

env DEVELOPER_DIR="/Applications/Xcode-13.4.1.app" xcrun xcodebuild -IDEClonedSourcePackagesDirPathOverride="$PWD/.dependencies" -derivedDataPath "$PWD/.derivedData" build -project "GRDB.xcodeproj" -scheme "GRDBiOS" -destination "generic/platform=ios"

The reality of it is that we are a small team and have more work on our plates than we can get to, as all open-source maintainers do. I can’t give you a timeline for implementing this, but I think this is the next logical step.

[groue]

Thank you @daveverwer, I'm glad you already thought about it, and we're in perfect agreement 🙂

Please forgive my weak memory, we indeed talked about .spi.yml already. And thanks for opening #1915!

I have absolutely no time constraint. Please just consider this issue as a request for enhancement :-)

[daveverwer]

Thanks @groue. I'll close this now in favour of #1915, but the context is linked with that issue when we get to it. I'll also ping you, so you can add the config.