<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 4:18 AM, Eloy Durán via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi SPM team,<br class=""><br class="">First of all, major congrats to you and the entire Swift team for your work so far and going public yesterday. I’m very glad to see this all happening in a true OSS way 👏<br class=""></div></div></blockquote><div><br class=""></div>Thanks!</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I’m reaching out on behalf of the CocoaPods team. CocoaPods and the Swift Package Manager will occupy a similar space, and we are now in the process of realigning our roadmap given what we know about the Swift Package Manager.<br class=""></div></div></blockquote><div><br class=""></div>Does CocoaPods maintain a roadmap for what features are planned / scheduled?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The Swift Package Manager has had the opportunity to plan its roadmap with knowledge of currently available solutions. We'd welcome a discussion of potential issues where our projects overlap, and together decide what's best for the community.<br class=""></div></div></blockquote><div><br class=""></div>Absolutely, we would welcome the same. Was there a specific discussion you were hoping to start on this thread?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">We already have some questions, but we’ll look into those ourselves first and otherwise send those out as separate emails. We understand you’re probably also very busy in these first few days after the announcement so for now I’ll leave you with best wishes and that we’re looking forward to working together towards best solutions for the community.<br class=""></div></div></blockquote><div><br class=""></div><div>Thanks for reaching out, I would love to find ways for all of us to collaborate. I think we all want the same thing -- beautiful, easy, scalable development and a rich ecosystem.</div><div><br class=""></div><div>Here are some of my random initial thoughts/questions/ideas from a purely technical perspective:</div><div><br class=""></div><div>1. Is CocoaPods technically able to use Swift-based libraries? If there were clear factorings of support functionality that we could build as, say, SPM packages, would CocoaPods be able to use them?</div><div><br class=""></div><div><div>2. The chicken and egg problem is something which makes evaluating design choices very difficult. Informally, the rule that Max and I have often talked about is that "80%+ of projects" should be able to use the convention based system with only the "leading package specification" (let package = Package(...)) and no other custom configuration. However, we can't currently objectively evaluate whether a particular design choice satisfies that criteria without a large body of projects that already work (or almost work) with SPM. I would like to investigate whether we can make use of CocoaPods existing corpus of projects (and infrastructure for testing them) for these kinds of purposes. This would help us quantify things like "this is how much work X percent of projects have to do to adopt SPM" and "X percent of projects need feature Y to work".</div><div><br class=""></div><div>3. One of my personal beliefs is that part of the reason software packaging & integration has historically been so messy is because no one has been able to be a "force for change" and <b class="">cause</b> projects to adapt. For C/C++/Obj-C projects, there are a lot of "unnecessary" variations in the project structure which add complexity for very little overall gain. For example, some things are simpler if you can assume that any package X installs its headers neatly under an "X" subdirectory -- but since historically this was never done, no has ever been able to encourage projects that don't do this to change.</div><div><br class=""></div><div>One of my hopes is that, eventually, Swift and SPM support can function as this force for change. If we can come up with a stricter set of requirements that improves our ability to make a very reliable, smooth development experience, then it may be that the value of supporting Swift and SPM is enough to encourage upstream projects to undertake the pain of changing their code base to meet those requirements.</div><div><br class=""></div><div>We saw this with Clang once OS adoption (e.g., FreeBSD, Darwin, Linux kernel) began -- initially there was a lot of push back on Clang to support every single GCC-ism that existing projects relied on. However, once it became clear that supporting Clang added value to the project, people started updating older projects to accommodate Clang.</div><div><br class=""></div><div>The reason I bring this up in relation to CocoaPods is that I suspect CocoaPods is currently in the camp of "we have a large body of existing clients and cannot aggressively try and simplify our model if it means they need to change", whereas for SPM we are much more likely to be in the camp of "we would like to require all projects to behave this way, even if it means many existing projects will need to be adapted, because we think it will allow us to build a better experience in the long run".</div><div><br class=""></div><div>What is your perspective on this problem? How big of an issue has this been for CocoaPods to evolve?</div><div><br class=""></div></div> - Daniel</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Kind regards,<br class="">Eloy Durán<br class="">_______________________________________________<br class="">swift-build-dev mailing list<br class=""><a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-build-dev<br class=""></div></div></blockquote></div><br class=""></body></html>