Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Implement podfile.lock logic #191

Closed
sergeyzenchenko opened this Issue · 8 comments

3 participants

@sergeyzenchenko

I found an issue. I have a Podfile with

dependency "AFNetworking", "0.5.1"

if I will change version to latest "0.9.1" and run "pod install" it will say what "Using AFNetworking (0.9.1)", but it's not true!.
In file system I still have version 0.5.1 and it will works only if I will remove folder with pods and run "pod install" again. Same with changing version from newest to older.

@alloy
Owner

Yup, we have been cheating all this time and kept it real simple :)

There is already a ticket for this, #131, but it’s implicit, so I’ll leave this open.

@sergeyzenchenko

I dont want to wait to 0.7 version :) I've forked it and going to fix it. Do you have any useful information about this issue what can help me?

@alloy
Owner

Sweet!

You will have to use YAML to read the Podsfile.lock file and check the currently installed version, and then update the library if the version in the Podfile file is higher.

You can use the Pod::Version class to compare the versions.

@sergeyzenchenko

I think we should update if version in Podfile is different from lock file, not just higher. User can set lower version for example.

@alloy
Owner

Yeah indeed.

@fabiopelosin
Owner

Moving this to 0.6.1 as everybody is expecting it to work.

@alloy
Owner

I’ve just added a wiki page about how we should imo proceed with releases in the future, this also means we need to evaluate our way of dealing with milestones. Since this is a feature addition it would bump the minor version, but that does not mean it has to be far in the future.

@fabiopelosin
Owner

I've updated the title title of the issue.

@fabiopelosin fabiopelosin referenced this issue from a commit
@fabiopelosin fabiopelosin Introduced Pod `update`, `outdated`.
See #131, #191.

- The installer is initialized with a resolver. The resolver is responsible of
  indicating which specs must be installed/reinstalled.
- It was introduced a slight change in the format of the Podfile.lock.
- The specification set was simplified to receive and handle Pod::Dependency
  instead of Pod::Specification. With this change it also appears to be more
  robust.

A this stage it appears to be working. However the support, for external and
head dependencies is weak.
34a6853
@fabiopelosin fabiopelosin referenced this issue from a commit
@fabiopelosin fabiopelosin Introduced Pod `update`, `outdated`.
See #131, #191.

- The installer is initialized with a resolver. The resolver is responsible of
  indicating which specs must be installed/reinstalled.
- It was introduced a slight change in the format of the Podfile.lock.
- The specification set was simplified to receive and handle Pod::Dependency
  instead of Pod::Specification. With this change it also appears to be more
  robust.

A this stage it appears to be working. However the support, for external and
head dependencies is weak.
21b42a0
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.