Firstly, great project - very interesting!
Your README states:
By contrast, Carthage has been created as a decentralized dependency manager. There is no central list of projects, which reduces maintenance work and avoids any central point of failure. However, project discovery is more difficult—users must resort to GitHub’s Trending pages or similar.
Carthage doesn't rely on a central list of projects, which i understand. But I presume it in no way prohibits someone (perhaps the Carthage team) from creating a list of projects that are compatible?
My feeling is that this is necessary for this idea to be a success.
For a project to be compatible, it needs a tagged version of an Xcode project containing a shared scheme that builds a framework.
Assuming the project in question already builds a framework, it should just workâ„¢. A centralized list of projects would grow very long, very quickly. What do you think the benefit would be?
Personally, I'd rather see a simple web service that gives me a Carthage compatible badge by checking everything is correctly configured to be picked up by Carthage.
What do you think the benefit would be?
One word - discoverability!
Every other mature dependency management tool I have used has a mechanism for searching and browsing libraries and frameworks.
Sure, you don't _need_ one, and I very much like the way that making any of my libraries Carthage complain is simple (I have a few pods), however developers are lazy (I know I am), I like having a big long list I can just browse all in one place.
NPM is probably one of the best, giving you some real insight into how actively packages are developed.
Fundamentally, I just don't think that this is within scope for Carthage. If Carthage is fully functional and usable without a centralized list, why would such a list be part of the project's mission at all? Anyone could do it, and Carthage would benefit, so making it official just means increased maintenance work and scope creep.
But, more to the point, we already _have_ a centralized list: GitHub. There are plenty of tools in https://github.com/explore for discovering projects, plus the innumerable Cocoa blogs, publications, Twitter accounts, etc. that recommend new and interesting things all the time.
CocoaPods is another such list. It might seem silly to use the CocoaPods package list to find projects for use with Carthage, but why not? The work is already done, and there's no reason that we need our own parallel list. Discoverability is one of the big goals of CocoaPods, after all.
TLDR: Centralized project lists already exist—but even if we wanted another, I think it should be handled by the community, instead of confusing Carthage's mission and purpose.
Fair enough - like you said, the community is totally free to build one.
@jspahrsummers hadn't spotted that this is another one of your projects? When do you sleep ;-)
Indeed. :wink:
I'm contemplating building a site that would essentially allow you to register your carthage compatible project and it will give you metadata about the project and where to find it.
@ColinEberhardt do you still think that this is something that is useful for the community?
I totally agree that the decentralised nature of carthage is key, but a registry where you can lookup a project seems pretty useful. I know it's something I'd like to have.
Food for thought...
@modohash I'm sure people would find this useful.
Yesterday I added support for Carthage to Libraries.io: https://libraries.io/carthage
It finds packages by finding all the open source repositories referenced in all the Cartfiles across every open source project on GitHub, so far it's found about 450.
That's pretty sweet, I'll be sure to use this when looking for carthage packages!
Most helpful comment
Yesterday I added support for Carthage to Libraries.io: https://libraries.io/carthage
It finds packages by finding all the open source repositories referenced in all the Cartfiles across every open source project on GitHub, so far it's found about 450.