search

JamitLabs / Accio

A dependency manager driven by SwiftPM that works for iOS/tvOS/watchOS/macOS projects.
MIT License
664 stars 32 forks source link

Leverage Swift 5.1 module stability #64

Closed fredpi closed 4 years ago

fredpi commented 5 years ago

An idea originating from #62, if the Swift version, let it be v, is greater than 5.1 (the Swift version where module stability is introduced), the cache should also be looked up for versions built with a version w, v ≥ w ≥ 5.1. If a cached build product with version w is found, then it can be used, even with Swift version v.

Jeehut commented 5 years ago

I haven't tested that, but given this actually works with dynamic frameworks I think we could support this feature with an option at first. My reasoning is that although ABI stability is a given now, we still don't know how things go in practical terms and especially given that some frameworks might opt for adding some new features only for newer Swift versions, we might miss out on supporting the latest technology if we make this the default behavior.

Not sure if I explained it well, so here's an example: Let's a framework – let's name it X – introduces a new syntax or new API in version 2.0 only for Swift 6.0 users and has a fallback for Swift 5.1 users which is less concise but still works, and let's say that someone is still running on Swift 5.1 although Swift 6.0 is released, then this user will build that framework with Swift 5.1 and cache the results. Then, when she updates to Swift 6.0 sometime later, she will still get the Swift 5.1 API since it was built with Swift 5.1 – at least that's how I understand it (haven't tested though). This way defaulting to always using compatible cached versions might make users miss out on new features and get confused, why they are not available. Also, optimizations on Swift performance might not automatically be apparent on those cached products.

Also, given that new Swift versions do not appear so often, I think we can comprise having to build dependencies twice a year or so. By the way, I don't think we should in any way optimize for using Beta versions at all. Having this all said, I'm not against adding this as an option for those, who need this.

fredpi commented 5 years ago

@Dschee Not enabling this by default totally makes sense to me, but I'm uncertain whether anyone would actually use a flag with the install / update command that manually enables such a behaviour... Therefore, this is probably not worth implementing at all, is it?

Jeehut commented 5 years ago

I think given Apple was quicker than expected with integrating SwiftPM into Xcode renders many features "not worth implementing", including this. We shall have to play around a little more with the given inclusion into Xcode and from that drive a new direction for Accio to go. I feel like there's still space for Accio here to provide a bridge between now and the time all frameworks properly support inclusion into Xcode via SwiftPM. They are still missing resources support, for example ...

fredpi commented 4 years ago

Closing this as not worth implementing (see discussion above)