We have a lot of the normal developer key commands working as expected, if there's something you'd want that we don't support, write us an issue or PR. The app gives direct feedback as you're editing the Podfile: One of the things I'm really happy about is our inline errors for your Podfile. The key features for 1.0 are being able to edit a Podfile, and to be able to run pod install and pod update on it. If you've not looked at XPC it gets a thumbs up from us. This protects the app from crashes, keeps memory usage low and doesn't require booting up Ruby every time we want to communicate. XPC means that we can have a persistently running Ruby environment from which we can send/recieve metadata about Podfiles. We negated the need for this by moving to communicate with Ruby over XPC, we called this the ReflectionService. We built support for bi-directional communication between Objective-C and Ruby using Rub圜ocoa.Īt one point we had a fork of Rub圜ocoa that supported objects created in Swift, but that was probably going to turn into a long road for something with not too much gain on our end. There is however a bridge that used to come shipped with Mac OS. There have been a few tools which bridge Ruby and Cocoa, the most notable being RubyMotion. It's effectively a one way communication pattern. This makes it easy to run commands, but it can be hard to deal with interactivity. The simplest option is via NSTask, which will execute a command in a shell and output text to STDIN and STERR. The CocoaPods app needs to talk to the pod command provided by ruby. I've been using it as my main pod command for the last few months. Ace.Īs it has the same name, you don't need to change any scripts or your development flow in the terminal once installed. This means once you've installed it, you can move your app freely, and we don't need to update the C binstub.
The binstub finds the embedded ruby pod command generated by RubyGems and passes along the same arguments. The pod command is a C binstub which uses the Core Services API in order to work independent of the CocoaPods.app which installed it.
We do this in the same way Xcode does, by offering command line tools: Instead we offer a way to access the command-line interface with the version of CocoaPods that is inside CocoaPods.app.
We don't plan on replicating every feature of the command-line gem in the CocoaPods app. I aim to always put up designs early for features, making it easy for people to contribute with a specification in mind. We keep a well stocked issue cabinet with well marked out issues for people wanting to help out. It's cleanly built using simple composition, and has been the source for quite a few people's first open source contribution.
0 kommentar(er)
