[swift-build-dev] Hello SPM

[Paul Young]

Glad to hear about the potential for collaboration here!




Daniel – I wanted to support your comments by saying that when Carthage shipped, it required projects to have build schemes defined (and shared). This highlighted projects which _didn’t_ have one or both of those things, and it’s my understanding that it prompted updates along those lines.




My perception of this is that:

a) people hadn’t created (shared) schemes because they didn’t know about or understand them, rather than purposefully avoiding them

b) people were happy to make the changes because the benefit outweighed the effort

c) this was often referred to as “adding Carthage support” but was really just adding standard Xcode behavior

d) projects were more accessible outside of use with Carthage as a result




All this to say – I think having a preferred way of structuring projects would be welcomed, despite some instability in the beginning.

On Sun, Dec 6, 2015 at 7:32 PM, Daniel Dunbar via swift-build-dev
<swift-build-dev at swift.org> wrote:

>> On Dec 6, 2015, at 4:18 AM, Eloy Durán via swift-build-dev <swift-build-dev at swift.org> wrote:
>> 
>> Hi SPM team,
>> 
>> 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 👏
> Thanks!
>> 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.
> Does CocoaPods maintain a roadmap for what features are planned / scheduled?
>> 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.
> Absolutely, we would welcome the same. Was there a specific discussion you were hoping to start on this thread?
>> 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.
> 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.
> Here are some of my random initial thoughts/questions/ideas from a purely technical perspective:
> 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?
> 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".
> 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 cause 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.
> 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.
> 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.
> 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".
> What is your perspective on this problem? How big of an issue has this been for CocoaPods to evolve?
>  - Daniel
>> Kind regards,
>> Eloy Durán
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151206/e15ece93/attachment.html>