Exclude specific schemes via Cartfile.ignore

[Jeehut]

Closes #1227, #437 and maybe more.

Goal

My goal ist to ensure that with a Cartfile that looks like this:

github "Moya/Moya"

Which would normally build Moya, RxMoya, ReactiveMoya, Alamofire, Result, RxSwift and ReactiveSwift. To introduce a new file named Cartfile.ignore with something like this content:

# Ignore RxSwift variant of Moya
scheme "RxMoya"
scheme "RxSwift"

# Ignore ReactiveSwift variant of Moya
scheme "ReactiveMoya"
scheme "ReactiveSwift"

Which leads to Carthage only building Moya, Alamofire and Result.

In detail the structure of the Cartfile.ignore is highly inspired by the structure of the current existing Cartfile. Instead keys like github and git the .ignore file should only support scheme.

scheme

This is the first step I want to reach – to ensure all schemes with the name specified after a scheme entry within the Cartfile.ignore are not built when running Carthage tasks. Note that the user is being notified about this with something like *** Ignoring scheme "RxMoya" in Moya.xcworkspace.

UPDATE NOTE: Originally I also had the suggestion to introduce a project keyword which would then even prevent from downloading the dependency. See the section "Where to go from here" below where I consider an alternative for that which can be added later on, in a subsequent PR.

---

Please also note, that since this change is purely additive, there should be no side effects whatsoever to any Carthage users who don't specifically create a Cartfile.ignore to use this feature.

Use the Cartfile.ignore right now via Carthage-Pro

I created a fork of Carthage until this gets merged (which might take years) which includes this feature already. Please read this comment further below for additional details.

Where to go from here

Here are a few "Next Steps" possible after this PR is merged to go further into this direction:

• Add the possibility to ignore a dependency even during dependency graph resolution by adding support for entries like github "ReactiveCocoa/ReactiveSwift"
• Consider the Cartfile.ignore in dependencies during dependency graph resolution so framework authors can improve the build time for their Carthage users without extra-work for them

[BobElDevil]

So I do like the aspect that this is like "Cartfile.private" and only applies at the top level of the dependency graph when run. Then it's entirely the top level consumers job to figure out what they messed up, rather than multiple possibly incompatible dependency interactions. I'm not opposed to this, but I can't claim to be the official stance, so I'll defer on that.

Couple of comments on the actual structure though:

• There's actually 3 levels to consider here, not just 2. It's not 'project and scheme', it's really something like 'dependency, project, and scheme', where dependency is what's defined in the Cartfile, project is the 1+ xcproj files found in the dependency, and schemes are any schemes therein.
• With that in mind, I think we need to consider a different file structure, maybe YAML or json? Something that better supports a hierarchy. This way we can structure things at the granularity desired. For example given a Cartfile that contains github "example/MyRepo", I'm imagining rules along the lines (YAML for example purposes, any nested format would do)

# Ignore all schemes in all projects in MyRepo
- dependency: MyRepo

# Ignores schemes in MyProject.xcproj, but will not ignore other projects now because we've specified at the project level
- dependency: MyRepo
  projects:
    - name: MyProject.xcproj

# Ignores the MyTarget scheme of the MyProject.xcproj project, everything else in the dependency is not ignored
- dependency: MyRepo
  projects:
    - name: MyProject.xcproj
      schemes:
        - MyTarget

The other thing I'd like to see is somehow utilizing this to cover the other case of framework author wanting a scheme to never be built by carthage. The project/scheme specification would be identical in that case, the only difference is the rules of when to apply it. Maybe adding a special -dependency: current entry, or even just a top-level key current:, so we don't have the possibility of conflicting with a repo named 'current'.

At minimum, this file approach could be used for the latter as a stepping stone for the former

[BobElDevil]

Additionally I think we should limit the scope to just being a purely 'skip building this scheme' specification for now instead of also trying to skip it for fetching / cloning / resolution, as that gets into waterfall effects down to other dependencies

[Jeehut]

Thanks for the feedback @BobElDevil.

Actually I had thought about a more sophisticated YAML file at first, but then opted for a simpler solution. Also if you think that skipping the fetching/cloning/resolution part shouldn't be part of this PR (which I'm willing to agree on), then I think we don't even need the project option at all. Then I would suggest we just have a list of schemes to be ignored. Cause the only reason for me to add the project (or dependency) entry was to prevent the checking out steps, too. But you're right that those are not the biggest issue here as build time usually takes much longer than checking out etc.

So my suggestion is to keep my original approach using a non-yaml Cartfile.ignore and drop the project part entirely (those entries would be replaced with scheme instead). This should be relatively straightforward to implement and still should solve the most prevalent issue.

I'm not sure how my approach could be used to "utilizing this to cover the other case of framework author wanting a scheme to never be built by carthage" though. I think that we could initially start by inviting framework authors to extend their "Carthage installation" section in their README with a list of schemes that could be added to the Cartfile.ignore depending on the required feature.

For example Moya could state that users who don't want to use the features should add RxSwift, RxMoya, ReactiveSwift and ReactiveMoya to their listed schemes in their Cartfile.ignore. And AWS could have a list of all schemes and encourage their users to comment out those schemes with a # at the lines beginning that they actually want to use.

[Jeehut]

Note that I'll not have access to a computer until Monday, so I'll not be able to update the code to reflect any further discussed changes. But I'll try to answer on my phone to keep the discussion going.

[BobElDevil]

So my suggestion is to keep my original approach using a non-yaml Cartfile.private and drop the project part entirely. This should be relatively straightforward to implement and still should solve the most prevalent issue.

I still think you would need at least one level of depth, for repos that have multiple project files. It's possible that both projects have schemes with the same name, and if we only gave scheme names, then we'd filter out both or none. Though this could be accomplished by having the 'scheme' specification syntax be able to take a project file name along with it, e.g. ProjectFile/Scheme. Could even allow a 3rd layer that does specify the repository (repo/ProjectFile/Scheme), if you need that distinction. Doesn't quite have the flexibility of the rules you can achieve with a nested structure since you always need to specify down to the exact scheme, but this way we can keep the simpler file format by having a single line per specification.

I'm not sure how my approach could be used to "utilizing this to cover the other case of framework author wanting a scheme to never be built by carthage" though. I think that we could initially start by inviting framework authors to extend their "Carthage installation" section in their README with a list of schemes that could be added to the Cartfile.ignore depending on the required feature.

For example Moya could state that users who don't want to use the features should add RxSwift, RxMoya, ReactiveSwift and ReactiveMoya to their listed schemes in their Cartfile.ignore. And AWS could have a list of all schemes and encourage their users to comment out those schemes with a # that they actually want to use.

Sorry I was referring to my original suggestion for framework authors. I agree that in the cases you mentioned above, it would need to be some sort of recommendation from the authors to the users.

The use case I'm referring to is "I have a scheme that builds a bunch of extra stuff only needed for development, but it's shared so my coworkers can use it too". This is a scheme that no user would ever need to build, so it should be specified to be excluded by the framework author themselves. For example

# When running carthage from this repo, skip RxMoya. Don't skip it if this repo itself is being pulled in as a dependency
scheme "RxMoya"

# When the current repo is being built as a dependency, always skip MyDevelopmentScheme. This is limited to the current repo, this will not try to skip schemes located in nested dependencies.
scheme-current "MyDevelopmentScheme"

So once everything has been checked out, when carthage is about to run a build, it will filter all the schemes it finds by removing

• any scheme found in the current repo ignore file specified via scheme
• Any scheme found in the dependency being built's ignore file specified via scheme-current (I'm not attached to that naming though)

Note that these two cases can be tackled separately, I was only bringing up that they would want to use the same syntax and file format, so it makes sense to me that they'd end up in the same file, with some sort of marker to distinguish the usage

[Jeehut]

Yes, I agree that that would be a useful addition. But as you said it could be made in an additional PR. There the exact name could be discussed as well, but I would like to keep this PR lean and support the framework consumer side only.

Regarding the different projects, I‘m not sure what you mean. Could you show me an example framework where this would be required?

[BobElDevil]

Sorry it took so long to respond. But anyway, it's non standard, and I actually don't have an example that's not a private repo, but it is possible to name a scheme whatever you want, for example "Framework", and it doesn't have to match the target name. so you could have Framework1.xcodeproj and Framework2.xcodeproj both have a scheme named 'Framework', but it produces different targets (Framework1.framework, Framework2.framework). Without being able to specify which project file to filter, you'd have to filter both of them or none. So I was just trying to future proof it a bit by adding an extra level of clarity to the spec.

[Jeehut]

So rather than scheme we should use framework in the file? Is that your suggestion?

The reason I included scheme was that Carthage tells us when building the dependencies Building scheme "X" so I naturally thought there must be a list of schemes somewhere in the code which we can easily filter. If the same is true for frameworks as well, I have no problem with this change. But I'd like this PR to be as simple as possible, with a simple Cartfile.ignore structure and a simple implementation change. Cause otherwise I've got the feeling that this might not get merged too soon.

[BobElDevil]

I just meant prefixing your current scheme idea, specifying both project and scheme, to help differentiate. So from my example above you would say

scheme "MyFramework1/Framework" to skip the one scheme but not the other. It shouldn't add much complexity to this PR since at the point where we're getting schemes we know which project it came from

[Jeehut]

I see, makes sense. But it shouldn‘t be mandatory to specify both, it should still be possible to just list the scheme name. Then I‘m okay with your enhancement.

[BobElDevil]

yeah, that's ok with me 👍

[Jeehut]

Okay, sorry for not getting back to this the last few weeks, I've been on vacation and after that had some other work to get going the last few days (see my new project here).

Now this PR is the next thing I'd like to tackle, so expect some work on this until next week.

[Jeehut]

I've tried implementing this several times, but I just didn't succeed in filtering the schemes with the schemes from the Cartfile.ignore. I just couldn't find the right place for it and also I don't really understand how to deal with all the reactive stuff. @BobElDevil Would you mind helping me out there, maybe? That would be awesome!

[Jeehut]

I really need this feature a lot, could anybody help me with the reactive part a little? I'm grateful for any help there ... @BobElDevil @mdiep @ikesyo

[flockoffiles]

Is there any progress still expected on this PR? (Or it will be abandoned?)

[pmairoldi]

@Dschee im looking into continuing your work. What did you need help with? Implementing the logic of skipping schemes?

[Jeehut]

@petester42 Yes, exactly. My problem is that I never used reactive programming, therefore I'm having troubles to find the right place to actually filter / ignore the schemes found in the Cartfile.ignore. Also, I have no idea, where the Cartfile.ignore should be read, how I get the answer from the reactive stuff and where I can find the list of Schemes to filter. To me, all of the code looks like Russian: I can read most letters, but the meaning is different than I assume.

I just rebased my fork so there are no conflicts with the base branch. Feel free to fork my fork and post a PR to my fork. Then I can merge and update this PR. Thank you for your help, @petester42!

[mdiep]

Locking me out from the discussion in #2529, telling my (perfectly working) solution is "insufficient" and simply delegating the responsibility to "Xcode and SwiftPM to solve (this problem) down the road", and on top of that, asking me to rename my fork so it doesn't sound like it has anything to do with Carthage although it's a fork of it?

You're welcome to give your feedback here or in the other open issues. I opened (and locked) #2529 so that the core team can discuss the issue. That doesn't mean your opinion is unwelcome or unwanted. But there is a need for the core team to be able to discuss by themselves.

Your solution is working perfectly for you, but that does not mean that it's working perfectly. "Works on my machine" is not very helpful—especially for projects like Carthage that support a variety of work flows and a large number of external variables.

I noted that you haven't sufficiently identified schemes. I believe that the nesting of these exclusion files may also be underdeveloped.

I really don't understand why you guys don't want to solve this very apparent problem in a pragmatic way. My solution was only one possible way, there are others of course, but having an "insufficient" solution is still better than just waiting for others to solve this for you. And actually I did solve this problem for you, so you even didn't have to do anything except reviewing and merging. That's why I really don't understand what's going on here.

I appreciate you opening a PR to attempt to fix this issue. But:

1. I repeatedly told you that I didn't think Carthage should solve this problem. Rather than engaging in a discussion, attempting to convince me and solve the underlying design issues, you ignored me and opened a PR with how you thought it should work.

2. Writing code and opening a PR is by far the easiest part of this project. To say "you even didn't have to do anything except reviewing and merging" completely misunderstands how a large OSS project like this operates. The core team is responsible for what ships. You may have written code, but the team needs to understand it, accept responsibility for it, and maintain it going forward. That is by far the bigger task.

This is exactly why I chose to lock the discussion in #2529. I'm happy to discuss this issue with you, but this back-and-forth about your specific implementation, the timeline, etc. would sidetrack from that discussion. That's why I wanted to keep this separate.

[mluisbrown]

I have to say I find @mdiep's reaction very disappointing:

• The issue that this PR tries to solve is clear and present, and has been raised many, many times.
• The PR has been open for more than a year, without anyone in the core team raising any of the issues that Matt has now suddenly raised (at least as far as I'm aware).
  EDIT: the issue was discussed in Skip schemes #1227, although my reading of that doesn't suggest that any PR would be a futile endeavour, merely that the core team had some reservations and other priorities.
• Then when the code has been reviewed, and it looks like we might be getting somewhere, the entire purpose of the PR is unceremoniously dumped on, and to make matters worse, a private issue is created where only the core team are allowed to discuss it.
• The problem at hand continues and any solution is hand waved away to "one day this will be handled by SPM" 😕

Quite frankly, any potential contributor to this project seeing this PR would likely not want to touch it with a 10ft barge pole. I mean, with this attitude why is Carthage even OSS?

[mdiep]

The PR has been open for more than a year, without anyone in the core team raising any of the issues that Matt has now suddenly raised (at least as far as I'm aware).

The core design issue was discussed in #1227 several times—before this PR was even opened.

Mar 13, 2017:

This stinks, but it's really an issue with the AWS SDK—not with Carthage.

June 14, 2017:

I do think that makes some sense. I definitely agree that this is a framework author issue; not a framework consumer one. And ignoring certain schemes definitely seems like the easiest way to do that.

Where this has been stuck in the past is in how to specify that. In the past, we've talked about a general file that can accept these sorts of things using OGDL. (You can search issues/PRs for mentions of this.) I don't know whether that actually makes sense or not.

We can consider a reasonable proposal for how to specify that. (It might be done best as a PR to the documentation.)

June 14, 2017:

There are 2 orthogonal issues here: (1) framework authors who have schemes that should never be consumed and (2) consumers who wish to avoid extra work during building.

I'm sympathetic to (1), but feel that (2) is adequately addressed by binaries and caching.

There are several more responses after that.

Quite frankly, any potential contributor to this project seeing this PR would likely not want to touch it with a 10ft barge pole. I mean, with this attitude why is Carthage even OSS?

I hope that's not the case. 😞 We love getting contributions.

Here's the takeaway I'd want everyone to have: for significant contributions, build consensus with maintainers before coding and opening a PR. A PR is one approach to solve a particular problem. That approach may not be the best approach to solving that particular problem. It's best to have agreement on the approach before doing it.

[tmspzz]

@mluisbrown

The PR has been open for more than a year, without anyone in the core team raising any of the issues that Matt has now suddenly raised (at least as far as I'm aware).

That's why multiple people review PRs...

Then when the code has been reviewed, and it looks like we might be getting somewhere, the entire purpose of the PR is unceremoniously dumped on, and to make matters worse, a private issue is created where only the core team are allowed to discuss it.

As you can see discussion is going on here too. No one is taking away you're ability to express your opinion as you're doing. I started the review process to get the discussion going. A civil discussion. I take full responsibility for this.

Quite frankly, any potential contributor to this project seeing this PR would likely not want to touch it with a 10ft barge pole.

I find this statement short sighted. Is there a rule somewhere projects should accept every PR they get? Also, instead of doing the work before discussion and then arguing, why not discuss the intentions ahead of coding? I don't believe you normally work this way, do you?

I mean, with this attitude why is Carthage even OSS?

Again, I find this statement short sighted too. It's a community tool built by everyone's effort. You can fork it and remix it just like @Dschee has done. It's also under MIT licence so you can literally copy the code and use it to make your commercial tool.

[brow]

I'm hoping to contribute to Carthage someday, and I do not feel discouraged by this thread. I think all parties are reading and responding thoroughly, even when (I suspect) they're feeling frustration. I can see this is a high-quality community.

I especially appreciate the time that @Dschee, @mdiep, @BobElDevil, and @blender have invested in communicating their thoughts.

I see several active topics in the most recent discussion:

• Will this PR be merged into Carthage? Could it be merged with some additional changes?
• Should there be a fork of Carthage while the PR is not merged? What name is appropriate for a fork?
• Is the way that Carthage generally handles contributions working well?
• Is this contribution being handled in the same way as Carthage generally handles them?
• What is the purpose or meaning of having a collaborators-only discussion in Schemes and Carthage #2529?
• Have I been mistreated in this interaction? Will I be mistreated this way in the future?

I think it will be difficult to make progress on all of these topics in the same thread. If you are actively participating in this thread:

• Which of these topics is your highest priority?
• Would you be willing to ignore the other topics and post specifically about that topic?
• Would you be willing to take a short break from posting and see what feels most important to you in one or two days?

[mluisbrown]

@blender

Is there a rule somewhere projects should accept every PR they get? Also, instead of doing the work before discussion and then arguing, why not discuss the intentions ahead of coding?

Of course not. @Dschee's intentions were clear before doing the work and this had been discussed. There's nothing in the discussion that says anything that might indicate a PR for this issue would get shut down. The core team had reservations, sure, and they had other priorities, but no more than that.

This PR addresses a clear need felt by many users of Carthage, it's not some random feature. What incentive is there to contribute to a repo where this kind of PR gets basically closed after all the work has been put in?

No discussion of ways in which it could be improved, issues with the implementation, etc. Just: "Sorry, it's a no. Core Team will discuss this issue privately"

@brow

The 2 topics that are of the highest priority to me are:

• Will this PR be merged into Carthage? Could it be merged with some additional changes?
• Should there be a fork of Carthage while the PR is not merged? What name is appropriate for a fork?

[tmspzz]

@mluisbrown I think you missed

So I believe we should close this PR. But we will see what the other Carthage members think.

Also: #1990 (comment)

[Jeehut]

I'm not going to react to all things said here anymore since I think I already made my point. The rest is left to Carthage contributors.

But going forward, what I care most (and always have) is that the issue #1227, which is basically about unnecessarily long build times when bootstrapping a new project, is solved somehow. I work for an agency which means we have many different projects and we need to change between different projects very often and thus need to bootstrap a new project quite as often. Since we are using Moya in nearly all projects, but also AWS in some, it is really frustrating to not only "grab a coffee" when waiting for Carthage bootstrap, but instead have to wait half an hour. And if something fails along the way (the RX libraries – which we don't use – tend to do so), we need to check the problem and react somewhere within those 30 minutes, which makes this even more frustrating.

So, as I already stated a few times, I don't really care about what the solution looks like, I just want this issue to be solved sooner rather than later. And any comment that basically reads like "we don't plan to solve this (soon)" will make me unhappy – @mdiep being the one to be the worst in this regard, as he doesn't want to solve this issue at all – and every comment in favor of a pragmatic approach that will actually solve this issue will make me happy.

And one last thing about why I might have overlooked what @mdiep said about this not being an issue of Carthage: I'm also a quite active Open Source contributor and project maintainer myself, so I know what it means to be one. But when I developed a tool which many people seemed to use, I felt a resposibility for those people and so long as multiple people reported about an issue about my tool – even if it didn't affect me or the ways I thought my tool should be used – I still tried to help them as good as I can to fix it without changing the core goal of my tool.

Since many people have reported about this issue times and times again, I was convinced (and I am still) that this is such an issue where the users of this great tool need something the contributors might not feel like is "core part" of their tool. But I had confidence in the feeling of responsibility of the contributors. This is exactly what I cannot understand here. Thus all comments basically saying "we know, many are reporting this problem, but we don't care" by not actively helping to solve this problem, are against my worldview and are also the reason why I agree with @mluisbrown that this is not a good sign regarding having an active and open community.

For one, I currently feel like, I would rather write my own dependency manager instead of improving Carthage ever again. And that's actually my plan now, so expect to see an alternative to Carthage from me sometime around this fall ...

[mluisbrown]

Since I can't comment in #2529 I have to comment here 🙈 :

@blender

Work to support SwiftPM packages

Definitely. However I think Carthage can be more. Also SwiftPM has no support for iOS, tvOS, or watchOS.

For many SwiftPM projects just running swift package generate-xcodeproj first will be sufficient to then be able to build the project with Carthage. For example: https://github.com/pointfreeco/swift-prelude

swift package generate-xcodeproj
carthage build --no-skip-current --platform macOS

Will build the project no problem (--platform iOS doesn't work in this case because the test targets use libraries not available in iOS, but that's a separate issue).

But this is orthogonal to the issue at hand. This particular project has a bunch of frameworks, which are all built (swift package generate-xcodeproj just creates a single scheme which builds everything in the project). The "just build the stuff I need" issue remains.

Also, this doesn't address the vast majority of projects used in iOS / macOS development which don't have SwiftPM support.

So sure, supporting SwiftPM packages is definitely something Carthage should be thinking about, but it won't solve this issue, and it's an issue that needs solving.

Overall I think that this is a very real problem. Just like the .private, the blacklisting does not travel upwards so there is no risk for other consumers.

It is true that this might not be a problem for Carthage to solve, but I would also say that there are many other problems, starting with the lack of strict rules on how developers set up their projects, that carthage had made it's own. The complexity added by this change is negligible in my opinion.

👏

[mdiep]

So sure, supporting SwiftPM packages is definitely something Carthage should be thinking about, but it won't solve this issue, and it's an issue that needs solving.

I wasn't saying that Carthage should use swift package generate-xcodeproj. I was suggesting that we use the information from Package.swift instead of adding more information to the Cartfiles.

[mluisbrown]

I wasn't saying that Carthage should use swift package generate-xcodeproj. I was suggesting that we use the information from Package.swift instead of adding more information to the Cartfiles.

Ok, that seems like a good idea. However, as has already been mentioned, even if working with SwiftPM could, in the future, solve the issue at hand, it's not a realistic to expect people having this issue to wait until then. They will either need to use a fork or abandon Carthage as a dependency manager altogether.

[zdnk]

Well, is this feature coming or not? I don't see it benefit anyone discussing it for another year.

I agree with @Dschee. Having long build times costs us a lot of money and it is honestly annoying. Our build times could be decreased so significantly if we could just ignore those schemes that we don't need.

[freak4pc]

Sorry for "upping" this and being late to this conversation but I actually like what @mdiep suggested in the "collaborators" thread. Whitelist and not Blacklist - and it definitely needs to take the repo in question. As simply ignoring a scheme without the dependency would lead to chaos in deep-dependency graphs.

#2529 (comment)

[aryan-ghassemi-ck]

2 years later and still no solution, should have gone with cocoapods :(

[Jeehut]

Hello everyone, I finally managed to bring my own dependency manager to life which fixes the issues we've had with Carthage in our team. It's mainly based on SwiftPM and also currently uses Carthages build command to ensure all Carthage compatible projects can be made compatible with it very easily (you just need to add a Package.swift file if it's not already there).

Please also note that I'm already making many popular Swift frameworks compatible myself to provide a bunch of frameworks that are already officially compatible.

The name of the new tool is Accio (like the summoning charm ✨ in Harry Potter).

It's main advantages over Carthage as of now are:

1. Allows to specify which schemes should be built and skips all others.
   (Skip schemes #1227, Exclude specific schemes via Cartfile.ignore #1990, allow frameworks to specify which schemes Carthage should build #1616)
2. Automates the linkage & cleanup of your specified frameworks within your Xcode project.
   (Automate copy-frameworks arguments — quite error prone #1131, Automate copy-frameworks command? #2605, Auto linking to project #145, Generate xcfilelists for copy-frameworks for Xcode 10 #2477, replaces Carting)
3. Automatically uses a device-local cache to prevent rebuilding the same commit of a framework for a different project.
   (Carthage doesn't cache build across projects (or CI builds) #2400, Issue #2400 Shared cache for built dependencies #2716)
4. Has an option to use a shared cache path (instead of the device-local cache) within a team so only a single person ever needs to build a specific commit of a dependency and all others in the team can reuse that cached build cutting off build times of the team considerably.
   (Replaces Rome)

Please check it out here:
https://github.com/JamitLabs/Accio

Feel free to open issues if you encounter any problems with it or if you have ideas on how it can be further improved to make dependency management a less nerve-wrecking task for everybody.

---

I would also like to take the chance to thank all contributors of Carthage who all together made this great tool possible and drove the entire community forward. I hope my tool helps to fill the gap between the time where Carthage alone was used for dependency management and the future time (which I suppose to be late 2020) where SwiftPM & Xcode will take over the entire dependency management task. Until then, let's add Package.swift files to all open source projects to make them both compatible with Accio and mostly compatible with SwiftPM's future versions today.

Cheers! 🍻