Replies: 2 comments 4 replies
-
+1 to both of these. The ecosystem has definitely moved to SPM and I think Tuist can reflect that safely. We were longtime users of Carthage but dropped it multiple years ago due to the support situation, and once SPM started supporting binary artifacts some of the benefits are now no longer even present. We keep a copy of the Package.swift and Package.resolved in the repo as well so that we can do checks like https://fossa.com/. Being able to have things like auto-updating and other tools that work on the Package ecosystem would bring a lot of convenience. |
Beta Was this translation helpful? Give feedback.
-
Hey folks 👋🏼
However, it comes at a huge maintenance cost for us. Every time there's a new Xcode version, our integration breaks, which is unfortunate and time-consuming. I think Apple will adjust the I'm curious about what everyone thinks. |
Beta Was this translation helpful? Give feedback.
-
Dependencies.swift
proved to be valuable for users because they can cache them using Tuist's caching capabilities and allows developers to overcome some challenges that they face when using Xcode's SPM integration, which resolves packages at startup time and invalidates them when users clean the environment.Because of this, I think we should further invest in it, but I think we should revisit some aspects of it. The following are some problems that I've noticed with our approach with proposed solutions.
Drop Carthage support
Carthage is not actively maintained since January. Moreover, a lot of teams are migrating or have fully migrated to SPM. Because of this, I think we should consider dropping support for it and reducing the support surface to narrow the focus to Swift Packages. Since Tuist provides interfaces to link against system binaries, developers can continue using Carthage, but they'd have to wrap the
tuist fetch
command in a script that also runscarthage build
(or the equivalent).I believe this change will be beneficial for the maintenance of the project because we have very limited resources and the focus can scatter easily
Dependency auto-updating doesn't work
Tools like Dependabot which have support for Swift Packages are not able to update dependencies because we don't follow the convention of Swift Packages. This prevents Tuist users from users dependency auto-updating tools. Because of this, I think we should revisit our approach. If we drop support for Carthage frameworks, we can adopt
Package.swift
as the interface for defining dependencies. It'd be aPackage.swift
with no targets, only dependencies. The current logic would require a few changes because it uses the SPM and a Package.swift internally. The only difference is that we'd make a public thing instead of an internal implementation detail.Beta Was this translation helpful? Give feedback.
All reactions