Select swift version

[acecilia]

Select swift version

[cgrindel]

I started digging into this. Here are my current thoughts/observations:

• The rules_spm code is definitely not finding the Swift binary correctly. I will work on updating the code to respect the Xcode selection better.
• The artifacts from rules_spm need to be built with the same Xcode version. Otherwise, compilation errors will occur.

main.swift:1:8: error: module compiled with Swift 5.4.2 cannot be imported by the Swift 5.3.2 compiler: /private/var/tmp/_bazel_chuck/acd478c94e4d22147ca64882e3ea61f8/execroot/simple_example/bazel-out/darwin-fastbuild/bin/external/swift_pkgs/spm_build/x86_64-apple-macosx/release/Logging.swiftmodule
import Logging

• Right now, it seems like rules_spm needs to follow the pattern that is laid out in the linked article.

[cgrindel]

OK. I should be able to start looking into adding DEVELOPER_DIR support later today.

[cgrindel]

What does rules_swift do to support different Swift versions? I haven't had to do this much myself. I have been trying to align with their conventions.

[acecilia]

@cgrindel they use xcode_version: https://www.smileykeith.com/2021/03/08/locking-xcode-in-bazel/

[acecilia]

Seems they use fragments for obtaining the xcode version: https://github.com/bazelbuild/rules_apple/blob/master/apple/testing/default_runner/macos_test_runner.bzl#L112

But I tried using fragments in a repository rule, and got the following error: Error in repository_rule: repository_rule() got unexpected keyword argument 'fragments'. Seems like repository rules cant use fragments 😕

[cgrindel]

I think that the solution is going to be:

• Use whatever swift is available in the repository rule. We are not building at this point, only fetching and generating descriptions.
• Leverage @build_bazel_rules_swift//tools/worker in the toolchain rules.

I am still poking around to confirm this.

[acecilia]

@cgrindel problem comes when:

• The default xcode selected results in swift version < 5.4
• The bazel configures an xcode that is different than the default, and that has swift version >= 5.4

In such case the rules will fail to generate descriptors due to swift version < 5.4

[cgrindel]

Yeah. That is going to be a problem. Right now, the only way I can think to work around that is to make sure that the default Xcode supports SPM at 5.4.0 or above. Once we get rules_spm working properly, a client can downgrade to a lower version of Swift using the techniques mentioned in Keith's article.

@acecilia Do you think that is reasonable?

[acecilia]

I currently suffer this issue in other repository rule, and the way I worked around it is by setting up the DEVELOPER_DIR env variable when running swift. Thus the initial proposal for allowing to customize the env. Not pretty, but works and provides control over the swift version used

[acecilia]

make sure that the default Xcode supports SPM at 5.4.0 or above

Sometimes this is not that easy. For example, in a farm of CIs: running sudo and having to do it in each one of them quickly becomes a problem. It also alters the state of the machine, which is usually problematic

[cgrindel]

@acecilia: I updated rules_spm to respect the Xcode selection that you pointed out. Thank you for that. With regard to the original proposal, I have a few questions:

If rules_spm did have an env parameter, wouldn't you still need to set the same value for rules_swift? From what I can tell, it would not be sufficient to just provide DEVELOPER_DIR to the SPM rules.

With regard to the CI machines having an Xcode version that is less than 5.4, I see two options for how rules_spm can support this.

1. Implement a parser and dependency discovery mechanism in rules_spm. This would remove the 5.4 requirement. However, as you can imagine, this would be a pretty big undertaking and be duplicative of the logic that is built into SPM.
2. Update spm_repositories with a parameter like package_descriptions which would allow the client to provide the description JSON. Then, rules_spm would not need to generate it, which eases the requirement for SPM 5.4 to be available on the CI machine. A client developer could generate the package description JSON and check it into source control. The primary downside is that the client developer would need to keep that package description JSON up-to-date.

What do you think about option 2? Am I understanding the problem that you are trying to solve?

[acecilia]

If rules_spm did have an env parameter, wouldn't you still need to set the same value for rules_swift?

Yes. Will need to use xcode_version for rules_swift and DEVELOPER_DIR for repository rules. Of course xcode_version and DEVELOPER_DIR point to the same xcode. I asked about this in slack and according to the answers this is the only way to select swift/xcode version in repository rules

What do you think about option 2? Am I understanding the problem that you are trying to solve?

The problem is the inability to select the swift version to use when the machine has multiple xcodes installed. I would say allowing to pass a value for DEVELOPER_DIR is a better option than option 2 explained above

[cgrindel]

OK. I think that I understand a little better. If we added support for DEVELOPER_DIR to rules_spm, you would have DEVELOPER_DIR point to a version of Xcode that supported SPM 5.4 or higher. Is that correct?

[acecilia]

If we added support for DEVELOPER_DIR to rules_spm, you would have DEVELOPER_DIR point to a version of Xcode that supported SPM 5.4 or higher. Is that correct?

Correct. In this case, I could use DEVELOPER_DIR to point to any xcode/swift version installed in the machine, despite the value of xcode-select

[cgrindel]

@acecilia PR #80 should auto-merge shortly. Do you mind taking a look at it to confirm that this is what you were requesting? I tried adding you as a reviewer, but it would not let me add you. I'll look into that later.

[acecilia]

Awesome, thanks 👏 🙌