Skip to content

'pod spec lint' & 'pod lib lint' have a large number of similarities and cross-over #1963

colinmcardell opened this Issue Mar 29, 2014 · 3 comments

5 participants


In reference to discussion in issue #1745, a refactor on the linting process might be appropriate. To continue this discussion, pull request #1959 does a poor job of resolving the crash that @theyonibomber was experiencing. @orta is cool.

CocoaPods member
Kapin commented Mar 29, 2014

Agreed. The linting process itself (including the CocoaPods/Core repo) needs some cleanup. I was working on a massive refactor to the backend to make things a bit cleaner and modular, but have been slammed the past few months. 👍*💯 to whoever wants to take on the front facing part of this.


Issue has been confirmed by @neonichu

CocoaPods member

Reporting my comment from #1745

Regarding the lint discussion I think that the commands should be kept separated... they do some very different things. pod lib lint checks wether the Pod locally works and pod spec lint checks that the pod form the remote works. As I might want to check the Pod from the remote without a local check out pod spec lint has still an important place even with trunk.

They could be merged and the logic could be something like:

  • If there is a podspec in the working directory matching the name of the given Pod (or if no name was given and there is a podspec in the working directory) perform pod lib lint.
  • Then if the podspec has an source attempt a pod spec lint and inform the user in case the failure was related to not being able to fetch the pod.

This is too much magic for my tastes and makes the execution of every command longer (what if I want to lint a huge library against the remote). I still agree that more clarification should be provided to the users about their usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.