Podfile.lock, pod update, pod outdated #447
Conversation
|
Tests are green and apparently this is not breaking existing behavior. |
| outdated_specs << spec | ||
| end | ||
| end | ||
| outdated_specs |
There was a problem hiding this comment.
What happens here? The outdated_specs are never used as on line 51 an empty array is returned instead.
There was a problem hiding this comment.
This is a preliminary version in reworking the architecture while maintaining the compatibility with the existing behavior. I've focused in working out the logic and more commits are coming soon.
|
Sweet!!!! One nitpick, a dictionary is called a hash in Ruby ;) So you want to include this change in the RC together with the private/public headers change, right? |
D'ho!
I've interpreted your comment as you were of the idea of releasing it. So the release Anyway this pull will definitely need RC there are going to be some important changes. |
|
I think that I've opened the pull too early. Now we are in a good state where I didn't check the docs of bundler before implementing this patch because I didn't want to be influenced by it. Now I see that bundler takes a much simpler approach and the current behavior might be difficult to explain. So it is time to decide what those commands should actually do. Current implementationNote: if the folder of a resolved pod doesn't exist it is installed, any case (e.g. was deleted by the user.) Pod Install
Pod Update
Bundlers wayPod InstallInstalls everything except already installed pods, if they are still compatible with the Pod UpdateMake a new install regardless of the contents of Memo for other tickets
So @alloy what is your take? |
|
Note of warning : This version of CocoaPods has a modified |
|
Let’s see, if I understand it correctly, the difference between the current implementation and how Bundler does it is: pod install
pod update
I’m leaning towards Bundler's approach. Like you say, it's much easier to explain, which in itself is a good indication that it's the better thing to do, especially if you’ll be able to update a single pod, people should be able to do everything they need, without having to think too much about it. I also can't imagine the case where you would want to install updated versions of pods you have installed, but not install new ones. Imho, simpler is almost always better, especially if it's a user facing feature vs an internal one. |
It doesn't installs them but detects that were deleted. Just I'm not removing the folder for now for safety as the system is not proved to be reliable; there is an open ticket about it and I will implement it once tested. The key difference is that it doesn't updates the Pods if they are still compatible with a changed dependency in the Podfile. If you wan't to update them you need to call pod update manually. I'm not sure of what bundler does in this case. Example. pod "MyLib" = "= 1.0"
# Installs 1.0
pod "MyLib"
# Install keeps the 1.0 even if the 1.1 version is available. However `pod update` can update it.
pod "MyLib" ">1.0"
# 1.0 is not compatible anymore with the Podfile and 1.1 is installed.In other words it locks dependencies to the installed version if still compatible with the new Podfile. The other alternative is when we detect a changed dependency in the podfile we could resolve the version regardless of the previous installed one.
Agreed. |
I’ve just checked with Bundler and your examples is exactly how it does it and how I would expect it to work. |
|
Nice, so I just need to change |
|
No idea, but isn’t our version yet? |
|
Did you see my comment about the Podfile.lock incompatibility?
Just to be sure.
It is, I'm just looking to get it right and clean so we don't need to create incompatibilities in the future. Here is a sample: PODS:
- A2DynamicDelegate (2.0.1):
- libffi
- AFNetworking (1.0RC1)
- BlockAlertsAnd-ActionSheets (1.0.0)
- BlocksKit (1.5.1):
- A2DynamicDelegate
- DACircularProgress (2.0.0)
- InnerBand (HEAD from 0.0.1)
- JMImageCache (0.2.1)
- JRSwizzle (1.0)
- MWFeedParser/NSString+HTML (HEAD from 0.0.1)
- NoticeView (2.1)
- Objective-C-HMTL-Parser (0.0.1)
- PrettyKit (0.2.0)
- ReactiveCocoa (0.6.0):
- JRSwizzle (~> 1.0)
- SVPullToRefresh (HEAD from 0.2)
- TTTAttributedLabel (1.3.0)
- Three20 (1.0.11):
- Three20/UI (= 1.0.11)
- Three20/Core (1.0.11)
- Three20/Network (1.0.11):
- Three20/Core
- Three20/Style (1.0.11):
- Three20/Core
- Three20/Network
- Three20/UI (1.0.11):
- Three20/Core
- Three20/Network
- Three20/Style
- Three20/UICommon
- Three20/UINavigator
- Three20/UICommon (1.0.11):
- Three20/Core
- Three20/UINavigator (1.0.11):
- Three20/Core
- Three20/UICommon
- Underscore.m (0.1.0)
- libffi (3.0.11)
DEPENDENCIES:
- AFNetworking
- BlockAlertsAnd-ActionSheets
- BlocksKit
- DACircularProgress
- InnerBand (HEAD)
- JMImageCache (from `https://github.com/jakemarsh/JMImageCache.git')
- MWFeedParser/NSString+HTML (HEAD)
- NoticeView
- Objective-C-HMTL-Parser
- PrettyKit (defined in Podfile)
- ReactiveCocoa (= 0.6.0)
- SVPullToRefresh (HEAD)
- TTTAttributedLabel
- Three20
- Underscore.m (from `https://github.com/CocoaPods/Specs/raw/master/Underscore.m/0.1.0/Underscore.m.podspec')
EXTERNAL SOURCES:
- JMImageCache:
:git: https://github.com/jakemarsh/JMImageCache.git
- Underscore.m:
:podspec: https://github.com/CocoaPods/Specs/raw/master/Underscore.m/0.1.0/Underscore.m.podspec
COCOAPODS: 0.11.1 |
|
@alloy One last question is it fine for |
Yeah, I did see it, but then forgot about it :) What part is incompatible exactly and why?
What about the duplication of the external sources? Can we remove that from the
Yeah, |
Now only the external sources. As the
For simplicity I'm using the to_s method of Finally I'm looking to fine tune the output of the
A comparison of the previous Lockfile and the new one is available here. @alloy Let me know what is your take on this. A part from those minor details I think that the patch is ready for testing. What do you think? |
|
@alloy Did you miss the the previous comment? |
|
@irrationalfab Yes I missed it, sorry about that.
Meh, it’s not that important for now, we can clean that up later.
What was the reason you decided to replace it and why are you unsure if it was a good idea?
We don’t need a custom language, just YAML is good enough imo, that way we can just use the existing parser.
This seems to be an issue on Ruby 1.9 only. It can be fixed by encoding the result string as UTF-8:
They could be converted to strings before/after serialising/deserialising, but I don’t think it’s a big enough issue to care about, nor do I find it really ugly myself :)
I’ll try the patch tonight! |
Simplify the code by using the built in coder. I was unsure wether it was a good idea because the checksum issues and because we could have a little bit of more control on the formatting. However, as we will stay YAML compliant I think that we can clean up this part as well later, if necessary.
Perfect!
I'm looking forward to hear your impressions. |
Closes #463.
|
@irrationalfab So I think it’s getting in an RC state, what do you think? |
|
I think so, as well. Are you going to merge it? On 24/ago/2012, at 23:10, Eloy Durán notifications@github.com wrote:
|
|
I think it’s better if you do it :) |
|
Done! Should we release the RC? |
|
Before we release the RC, what was your roadmap plan with regards to these?
I do think we really need those in the final version. |
I think that we should include them in a future release.
I'm sorry, but this sentence is unclear to me. Do you mean in the final version of this release? Or that we should not include those features at all.
Regarding the first one is more a matter of how much we want to support
This is discussed in CocoaPods/Specs#202.
This is to prevent that you edit the inline spec, call pod install and nothing changes. I was planning to do a checksum of |
Yes, I meant in the final version of this release, but mainly the SCM reference point.
I don’t worry about that too much, as in my experience one usually goes from very loose version conditions to very strict ones near the end of the development on a project, so these versions will still be necessary in most cases where somebody is currently using the But I also think many people will use the
These ones are I think less likely to cause unexpected issues for users, so adding them later is fine by me. |
|
So should we release? |
|
Yes, let’s release RC1! :) I will work on the SCM part during the next week. |
|
🎷💃 Released! 💃🎷 |
|
Great news \o/ |
|
PARTY! 👻 |
|
Sorry, didn’t get around to work on the SCM stuff this weekend, should happen this week. |
|
@irrationalfab I’ve been working and thinking off and on about this for the last couple of days, I’ll push a proof-of-concept hack tonight. But this is definitely turning out harder than I had expected, because the info we need is too fragmented over several classes. So even if my hacking will work, I think we’ll need to re-think some parts of the architecture of working in install and update mode, but at least we’ll have all the info we need :) |
|
@irrationalfab Ok, here are the results of my experimentation: https://github.com/CocoaPods/CocoaPods/compare/lock-scm-commit. Basically what happens is the following:
Did you have a different idea on how to handle this? Or is the general idea in line with your ideas? |
|
PS, here’s a lockfile example: https://gist.github.com/3645541. AFIncrementalStore and JMImageCache already have new commits at the time of writing, with this lockfile you should see it installs specific commits, not HEAD. |
|
@irrationalfab I’m thinking wether or not we should maybe release 0.14.0 as is and postpone this to the next release. I now have a fair idea of what’s needed, but think that it might be more sensible to refactor and re-architect specific parts first, instead of after the fact, allowing for some more time to not rush it. |
|
@irrationalfab Another issue to solve is how we can identify at what commit a pod is in order to determine wether or not it should be removed and updated during a normal install. Maybe we should add a |
|
Note to self:
|
I think that this is a good idea. Regarding the patch I'm reviewing it and some comments are coming soon. |
I vote for a manifest inside the pods folder (a copy of the lockfile?) So with pod install can compare if there is any change in the lockfile. And reinstall the pods that don't match. This copy should not be included in source control and should be used also to check if the version of a pod changed. For example, I install a What do you think? |
However, I'm not sure about the possible complications.
Good refactoring is good!
I don't fully understand your point, pods with external dependencies, if installed, should come from a Podfile dep. If they are not installed they should have their dependencies provided by Lockfile and by the Podfile and those two should match. |
|
Last note currently if you don't run pod update the specs with head source remain unlocked, maybe we should print a warning. |
|
Hmm, for some reason I was waiting for more feedback, or I missed some of your feedback… I’ll read/answer tonight. Also, do you want to release 0.14.0, or do you want me to do it? |
|
I'm releasing it :-) On 10/set/2012, at 18:14, Eloy Durán notifications@github.com wrote:
|
|
Done! |
|
💥 😋 💥 |
|
Changes Unknown when pulling 811f98c on pod_update into * on master*. |
No description provided.