i’m not sure if there is anyone outside Apple willing to fund this work just yet, but would a solution based around Shallow Git Clones be something likely to be accepted upstream?
3 Likes
There’s support for package registries, the problem is that GitHub said that would be supporting that but they haven’t yet, which complicates adoption. I heard that when AI blew up they de-prioritized pretty much every non-AI initiative.
Tuist recently announced support for the registry. I haven’t tried it yet, and it seems you need an account (free as far as I can see) but they seem to support all packages listed by the Swift Package Index.
1 Like
As I understand it, Tuist's registry operates in support of their "cached dependencies" feature. That is, it's not a full registry that offers general publishing and downloads. Instead, it operates as part of their build process, where your declared packages are published on demand for your future integrations. But I haven't looked too closely at it.
IMO, registries are blocked by the lack of support in Xcode, and the still-missing solution to unique package identity and ownership that is needed to prevent squatting or malicious distribution. (e.g. If package identity is only determined by URL, someone could publish https://somegithost.com/alamofire/Alamofire and be on equal footing with the real one. And if someone else publishes the real Alamofire to a registry, they own it, which is also a big issue.)
1 Like
This. Our use case is with our own private GitHub repos, and from what I understand even if I’m willing to opt into a less secure model it’s currently not possible for me to configure SwiftPM to perform shallow clones.