Add support for "local mode" #156

Closed
radiospiel opened this Issue Mar 9, 2012 · 7 comments

3 participants

@radiospiel

A Local mode - i.e. some mode where you would not need to push to some server - could help during development- Here you can read how I use cocapods right now in a local workflow:

https://gist.github.com/2009100

A better support would be to

a) add a "pod reinstall" command, which checks for all referenced projects if they have changed (which could replace the somewhat awkward rm Pods/<project>; pod install combo)

b) and a "pod updatelocal" script, which would update the local repo of spec files

A local mode integration could probably move the local repository of spec files into, e.g., ~/.cocoapods/local, and this repo could be excluded from refreshing during "pod install"

@alloy
CocoaPods member

I’m not sure if I got it all correct, so correct me if I’m wrong, but basically you want to have a local spec repo which does not have a remote?

a) add a "pod reinstall" command, which checks for all referenced projects if they have changed (which could replace the somewhat awkward rm Pods/<project>; pod install combo)

#131 describes a good process of how we should update pods.

b) and a "pod updatelocal" script, which would update the local repo of spec files

A local mode integration could probably move the local repository of spec files into, e.g., ~/.cocoapods/local, and this repo could be excluded from refreshing during "pod install"

I think that introduces too much options. There's no real harm in updating all repos is there? Worse case scenario, we could check if the repo has a remote and skip it otherwise.

@alloy
CocoaPods member

Oh wait, I think I see what your script does now, it points to local copies of a repo instead of the actual remote described in the official podspec?

@radiospiel

Yes, thats right. The idea is to have the local development repo. The podspec is prepared for remote distribution already. What I would like to have (and what my script does) is to have an option for "distribution" on my local machine only. This way one could work on a component until everything is fine, and once it is, tag it with the target version number, push it to the remote, add the podspec file to the podspec and push that to its remote.

The script (well, it is more than a hack now) basically adjusts the source spec to point to some local dir, and copies the spec file to the "right" place. This makes it a much smoother workflow: Do something in the component, "push" it locally, go to the target project, reinstall . For sake of simplicity it keeds a local repo in "~/CocoaPads/Local" which will be managed by the script, and which is where ~/.cocoapods/local pulls from. Which makes one of both redundant, if only "pod install" would not want to pull ~/.cocoapods/local. ~/.cocoapods/local wouldn't even have to be a repo at all, just a specs directory.

Re updating: there is a difference between "remote" pods, i.e. pods that I do not develop, but only use, and pods that I am currently working on, i.e. are pulled from my local machine anyway. remote pods only change when one either changes the version in the podfile, or when a new version becomes available - meaning, they do not change often. Local dev pods, however, change often; that is the point, after all. So there should be a way to not check all pods when installing a pod update, and, yes, a "pod update " command would be pretty helpful indeed.

@radiospiel

After browsing CocoaPods issues I think that #51 and #128 relate somehow.

@fabiopelosin
CocoaPods member

What I would like to have (and what my script does) is to have an option for "distribution" on my local machine only. This way one could work on a component until everything is fine, and once it is, tag it with the target version number, push it to the remote, add the podspec file to the podspec and push that to its remote.

For pod development I use a different workflow that might be useful to you:

  1. Install the pod with pod install.
  2. Remove the directory of the pod under myproject/Pods.
  3. Simlink the folder where the pod is developed with ln -s (it is important that the link will match the name of the deleted pod folder).

That's it. This set up is live in the sense that you can edit directly your pod from the workspace where you are working. Also it is important to note that pod install will not touch your files because it does nothing if the directory of a pod already exists (although I don't know if this behavior might change in future.).

@radiospiel

hmm, live editing in the final app, I like that. Will give it a try, thanks!

@fabiopelosin
CocoaPods member

Closed by 8f7fef1.

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