search

CocoaPods / blog.cocoapods.org

The blog for CocoaPods
https://blog.cocoapods.org/
34 stars 38 forks source link

Blog post for 1.1.0 release #135

Closed benasher44 closed 7 years ago

benasher44 commented 7 years ago

CocoaPods 1.1.0 release blog post. Improvements mentioned:

More?

benasher44 commented 7 years ago

I haven't been able to run rake serve:drafts successfully yet. I hit this error:

blog.cocoapods.org [basher_1.1.0] $ rake serve:drafts --trace
** Invoke serve:drafts (first_time)
** Execute serve:drafts
Starting the server locally on http://localhost:4000
bundle exec jekyll serve --watch --drafts --port 4000
Configuration file: /Users/benasher/Code/Ruby/blog.cocoapods.org/_config.yml
            Source: /Users/benasher/Code/Ruby/blog.cocoapods.org
       Destination: /Users/benasher/Code/Ruby/blog.cocoapods.org/_site
      Generating... 
  Liquid Exception: undefined method `[]' for nil:NilClass in _layouts/post.html
jekyll 2.5.3 | Error:  undefined method `[]' for nil:NilClass
rake aborted!
Command failed with status (1): [bundle exec jekyll serve --watch --drafts ...]
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils.rb:66:in `block in create_shell_runner'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils.rb:57:in `call'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils.rb:57:in `sh'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils_ext.rb:37:in `sh'
/Users/benasher/Code/Ruby/blog.cocoapods.org/Rakefile:28:in `block (2 levels) in <top (required)>'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/Users/benasher/.rvm/rubies/ruby-2.0.0-p648/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/bin/rake:33:in `<top (required)>'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/rake:23:in `load'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/rake:23:in `<main>'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/ruby_executable_hooks:15:in `eval'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => serve:drafts

I don't have time now, but I do plan on debugging this later.

benasher44 commented 7 years ago

@DanToml a few questions for you:

  1. I feel like I'm missing some ways in which you can specify the Swift version in the podspec. I went based on your PR, but it seems like there might be pre-existing ways: spec.pod_target_xcconfig perhaps?.
  2. I didn't mention the Dir.chdir issue, but that a lot of what was going on there went over my head. This is mostly because I haven't spent much time digesting those parts of Xcodeproj. Do you think this deserves mentioning (cc @segiddins)? This was quite a wrench thrown at us by Xcode 8.
orta commented 7 years ago

So, believe it or not 1.1 contains a pretty useful feature from me too, big enough to warrant a mention.

Error Handling Improvements

Now when CocoaPods receives unexpected errors it will highlight existing issues that might be related in the console. This makes it easier to find the answer to common issues. We do this by using gh_inspector which you may have seen inside Fastlane too.

benasher44 commented 7 years ago

Definitely! Sorry I missed It. I think I've just had Xcode 8 / extension tunnel vision the past few months. Will update the PR soon.

If anyone has any other big updates I missed, please chime in!

benasher44 commented 7 years ago

@orta added verbatim + a comma.

endocrimes commented 7 years ago

@benasher44

1) the pod target xcconfig will mean people can't integrate with the wrong version I think, which is nice for correctness. .swift-version is solely for linting/pushing.

2) I think it's probably worth mentioning, because we sank a lot of time into it. Honestly still not sure of the underlying cause, but it looks like DevToolsCore might be triggering a kernel bug?

benasher44 commented 7 years ago

pod target xcconfig won't do both?

For the DevToolsCore issue, I'm happy to include a section if you write it up 😀. It could just be a sentence or two in the Xcode 8 section

endocrimes commented 7 years ago

@benasher44 I don't think so, because it needs to be in the root project not just the pod targets?

benasher44 commented 7 years ago

@DanToml if the project is swift version unspecified, then I think all that matters is all of the swift pods being integrated need to have the compatible swift versions

benasher44 commented 7 years ago

Oh wait no that's clearly wrong because of CocoaPods/CocoaPods#5846. Hm. Maybe we should just be using the pod's build settings as a source of truth for setting the swift version for validation. Then, .swift-version file just becomes another way to set the pod's swift version setting like you could in pod_target_xcconfig. I think this might help some of the existing swift version confusion for pushing pods.

benasher44 commented 7 years ago

Also, I'm waiting on the resolution of CocoaPods/CocoaPods#5860. It appears I may have gotten it wrong for standalone messages applications. If that's that the case, then messages extensions are just like any other extension, and I should remove that section from the post.

benasher44 commented 7 years ago

The other possibility for this swift version issue is the swift version unspecified is different than the swift version setting is not set at all.

AliSoftware commented 7 years ago

It doesn't feel clear to me how pod authors are supposed to set the Swift version if they support multiple.

For example I have pods that support both 2.2, 2.3 and 3.0 in the same master branch. Should I create a .swift-version file containing 3.0 so that if the hosting project is itself 3.0 then CP will set the Swift version of the pod target to 3.0 and profit of the more modern API of my pod? Or should I not create that .swift-version file so that CP knows it's compatible with both 2.3 and 3.0? And in that case will it default to 2.3 even if the hosting user project is set to use 3.0?!

orta commented 7 years ago

It only sets the Swift version inside the linter, if your lib supports source-compatible 2.3 and 3.0 then 2.3 is fine. We keep no metadata around.

AliSoftware commented 7 years ago

@orta got it. Then might need some more explicit explanations fort that paragraph then (suggestion above)

benasher44 commented 7 years ago

In case anyone hits that backtrace again, it was because I hadn't added myself to _config.yml and configured the author properly (should have fully read the README).

benasher44 commented 7 years ago

Alright, this is much closer to being ready now. I think the only thing left to add is something about CocoaPods/cocoadocs.org#473 if we do something there.

alloy commented 7 years ago

I’m missing updates on all of the speed improvements done in this release, I believe there were great optimisations done, no?

orta commented 7 years ago

Speed improvements may have been caused by the previous 1.1.0 releases - not sure personally

endocrimes commented 7 years ago

@alloy @orta Performance improvements were mostly in https://github.com/CocoaPods/CocoaPods/pull/5927, https://github.com/CocoaPods/CocoaPods/pull/5934, and https://github.com/CocoaPods/CocoaPods/pull/5837.

@dnkoutso can probably elaborate more.

dnkoutso commented 7 years ago

The performance improvements were mostly done for larger projects during pod install by caching the result of various methods that are expensive because they perform a lot of file I/O.

I think the tl;dr is that pod install time is significantly improved, especially for large projects.