feat: use suffixed repo name as package name

[watt]

Resolves #1057.

Following the recommendation from the discussion there, this uses the repo name suffixed with .rspm as the package name.

[watt]

From my quick read, it looks like passing package_name will be a noop if the package does not use the package access modifier. Is that correct?

That's my understanding, yes. I believe SwiftPM does this by default, using the package name in Package.swift.

[watt]

Seems that downstream compilation workers got confused by the @-prefixed package name and that caused tests to fail in CI. I've tweaked this slightly to trim the leading @.

[watt]

I'm having trouble confirming locally, but it seems like the failing tests are running with Xcode 14.3/Swift 5.8, which doesn't support the -package-name compiler argument. Is the expectation that rules_swift_package_manager should gate on Swift version, or should rules_swift be handling that?

[cgrindel]

I'm having trouble confirming locally, but it seems like the failing tests are running with Xcode 14.3/Swift 5.8, which doesn't support the -package-name compiler argument. Is the expectation that rules_swift_package_manager should gate on Swift version, or should rules_swift be handling that?

We should be using 15.0.1 in CI. However, we are not locking the Xcode version for most of the examples.

@brentleyjones @luispadron Should we put this functionality behind a flag or settable on the Bazel module tag class/repository rule?

[brentleyjones]

rules_swift should ignore that attribute when it's not supported. If it doesn't, we should fix it.

[watt]

rules_swift should ignore that attribute when it's not supported. If it doesn't, we should fix it.

@brentleyjones Should I open an issue on rules_swift? Not sure what the next step ought to be here.

[luispadron]

I can look at fixing that tomorrow if no one else has time, but rules_swift releases are sort of blocked right now as we get some other stuff merged so not sure when this repo could pick that fix up

[luispadron]

Could/should we flag this in this repo based on the swift tools version of the Package.swift?

[luispadron]

@watt @cgrindel Brentley and I discussed a lil and it probably makes more sense to gate the setting of package_name in this repository and not in rules_swift. Reasoning being SPM wouldn't set this flag if its in an older package specification and it might be odd to have rules_swift just ignore package_name without some warning/failure when it's not supported by the compiler.

[cgrindel]

it probably makes more sense to gate the setting of package_name in this repository and not in rules_swift

SGTM. What is the correct gate? The Swift tools version?

[luispadron]

Yeah I imagine that's how it works in SPM but haven't checked

[watt]

Just pushed an update that gates package_name behind the tools version. The semver parsing is naive but hopefully sufficient for this purpose. If not, please lmk!