Remove dependencies on Commander #74

Closed
wants to merge 9 commits into
from

3 participants

@samsonasu

First off, thanks so much for this library, it's been invaluable to our company.

This PR removes runtime dependencies on commander and enables programmatically setting the team so as to avoid the commander prompt. This was essential for us to completely automate actions for apple ids on multiple dev teams.

Also, it looks like the fix to #68 which requires that we include the values of a cookie in the add device request didn't in fact get merged: that issues is resolved by this pull request as well.

Finally this includes one more fix that doesn't re-submit your login info if it's incorrect (I got my apple id locked by this once).

I apologize for the messy commit history, I meant to issue pull requests as we were making these changes but it looks like you weren't around for a while so it wasn't a priority. If you'd like me to squash some of these I can probably do that.

@samsonasu

We shouldn't call teams_by_name twice in this method, it's a terribly slow method that does http requests

@mattt

Thanks for your pull request, @samsonasu, however Cupertino was designed to support non CLI functionality from the very start. You can simply interact with Cupertino::ProvisioningPortal::Agent directly from a Ruby script. Does that make sense?

@mattt mattt closed this Nov 13, 2013
@samsonasu

We do interact directly with Agent and it works mostly wonderfully! Thanks again for the great library.

The issues here are that the team choosing functionality was defined in an instance_eval block in helper.rb instead of in Agent, and that functionality invokes commander (i.e. choose) directly. If there is a better way to do this, I'm definitely open to changing the implementation.

We also moved the require for commands.rb to the binary, since having commander loaded was causing issues for us in a rails environment.

Let me know if there's anything else I can do, because it would be nice not to have to maintain a fork. Maybe this was addresses in part by #76, I'll take a look at that today.

@mattt

Ah, I see now. #84 appears to resolve this. Does the most recent version fit your use case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment