<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=""><div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Sorry, I wasn't clear here.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">What I meant was is the *implementation* of CocoaPods actually able to use Swift libraries. I'm wondering if it would ever be viable to factor out shared libraries that both projects used, but I can imagine that using (and installing) those libraries from the Ruby based CocoaPods might be non-trivial?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>Ah, I see. It would involve some work, but I’m sure it’s something we can overcome, when the benefit of sharing said components outweighs the complexity of writing some CRuby/Swift bindings. Right now I’m not sure which components that would be –maybe the Xcode integration part in the future?–, but we’ll keep this possibility in mind as we go forward.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I think both of those are things it makes sense to add soon (and encourage people to author).</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>Ace. I see you already commented on that Chocolat ticket, will answer there.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">One evolutionary approach I have considered is that we could, for C-family projects, provide built in tools to define adaptor packages which integrate non-conforming projects into the system. This is analogous to how we support module-map packages today, even though in an ideal world projects would ship module definitions with their project. This would allow the ecosystem to build up, and people would begin to see the value of it. At that point, the owners of the adaptor packages could upstream their work into the project itself. And then we would all live in a better world! :)</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>Oooh, this sounds good. I’d love to hear more about this when.if you have more details. It sounds like this might be an interesting place where we can provide an adapter that would make libraries covered by CP only to be usable by SPM while they are not natively supported yet, or ever.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">One of the specific things I was curious about was how CocoaPods has historically handled changes to the podspec definition format?</span></div></blockquote><div><br class=""></div><div>- A lot of build options would initially be set through a simple `xcconfig` dictionary and a `compiler_flags` list.</div><div><br class=""></div><div>- A big reason for me to choose Ruby for CP was that, because of Ruby’s nature:</div><div> * lib authors could amend the way a library was integrated with a Ruby post-install hook in their lib’s podspec that had complete access to the library integration code</div><div> * users could basically monkey-patch the complete system from their Podfile (the root spec, shall we say)</div><div> This was an often recommended (we’d give them code suggestions of how/what to patch) and ask them (both lib authors and end-users) to report back to us with the solutions they came up with.</div><div><br class=""></div><div>In both cases we’d use the data that we received, about what people actually needed, to decide what the podspec definition should look like. Because of this there haven’t been many podspec additions that we felt we needed to revert.</div><div><br class=""></div><div>Obviously this complete freedom comes at a price and now that we pretty much have everything in the format that we need we’ve started locking that down. Using the `xcconfig` dictionary is discouraged and the post-install hooks have been replaced from the podspec format for a shell command: <a href="https://guides.cocoapods.org/syntax/podspec.html#prepare_command" class="">https://guides.cocoapods.org/syntax/podspec.html#prepare_command</a></div><div><br class=""></div><div>(post-install hooks are still a supported and valuable thing in the Podfile format, though. The end-user should be able to do whatever they need.)</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">How does this work if a podspec and its dependencies start requiring incompatible versions of CocoaPods itself?</span></div></blockquote><div><br class=""></div><div>A ‘spec repo’ may contain a file that indicates what the minimal CP version that is required to work with the specs in that spec repo. The CLI tool simply stops working and informs the user to upgrade if their version is older than the minimal required version for that spec repo.</div><div><br class=""></div><div>For example, the minimal required version for the public central spec repo is 0.32.1 (over a year old): <a href="https://github.com/CocoaPods/Specs/blob/master/CocoaPods-version.yml" class="">https://github.com/CocoaPods/Specs/blob/master/CocoaPods-version.yml</a>.</div><div><br class=""></div><div>But as we use a simple DB for our index (FS, probably in a SCM repo) users that really can’t upgrade their CP version yet, or don’t want to yet because of other time constraints, can easily use an older tree / branch. (This is something that people, specifically larger companies, have definitely done in the past.) Because of this flexibility, we were free to make breaking changes when we really deemed them necessary.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Have you just managed to avoid this, or are there legacy features you have ended up supporting but wish you didn't need to? I see things like issue #840 which I assume reflects some of how this worked out in practice.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>* The Podfile format is indeed something that in hindsight is very clear should have been the way as described in #840 from the get-go, but it’s also going to be pretty much the only real big breaking change we’ll be making, so I don’t see it as a big problem. People have still been able to build their complex multi-platform projects, this API change would be a one time major clean-up of everything we now know people require.</div><div><br class=""></div><div>* Static libraries with resources were a major pain, because the way the lib code often referenced them (through the NSBundle API) meant that all the resources would have to go into the main app bundle, which could easily lead to duplicate filenames. We ended up adding functionality to create ‘resource bundles’ and over time lib authors started using this pattern more and more, but the complexity we needed to deal with for this is something I really wish we didn’t needed to deal with. <a href="https://guides.cocoapods.org/syntax/podspec.html#resource_bundles" class="">https://guides.cocoapods.org/syntax/podspec.html#resource_bundles</a>. We had hoped that dynamic frameworks becoming available on iOS would finally solve all such woes, but alas those tend to load way too slow (<a href="https://github.com/artsy/eigen/issues/586" class="">https://github.com/artsy/eigen/issues/586</a>). Have you given any thought yet to how you’d like to deal with resources and embedding those in a bundle?</div><div><br class=""></div><div>* Subspecs are something that I really don’t like and wish we didn’t need to support. <a href="https://guides.cocoapods.org/syntax/podspec.html#subspec" class="">https://guides.cocoapods.org/syntax/podspec.html#subspec</a>. It was pretty much only added to support the monolithic libraries that were being build, especially from the pre-iOS era. I don’t like having source that I don’t use in my app, which includes dependencies of such code. So the only reason we saw to deal with that was to allow a CP user to specify what subsets of the monolithic library they wanted to use.</div><div><br class=""></div><div> Subspecs make some implementation more complex than we’d like and I personally prefer the approach of micro libs and a spec for each, *but* I should add that many in the community actually really like using subspecs.</div><div><br class=""></div><div>* Another thing that I remember that I was very glad we got rid of was determining platform specific settings at spec evaluation time, which made specifications very hard to use in environments where users were targeting multiple platforms, let alone once more platforms were being introduced. i.e. you used to be able to do something like:</div><div><br class=""></div><div> common_files = ‘Common/..'</div><div> if config.osx?</div><div> spec.source_files = common_files + ‘OSX/…'</div><div> else</div><div> spec.source_files = common_files + ‘iOS/…’</div><div> end</div><div><br class=""></div><div> Nowadays you specify them all and their platform scope:</div><div><br class=""></div><div> spec.source_files = ‘Common/…’</div><div> spec.osx.source_files = ‘OSX/...’</div><div> spec.ios.source_files = ‘iOS/...'</div><div><br class=""></div><div>– Eloy</div></div></body></html>