New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CocoaPods workflow should be invisible to end-users #94

Closed
schwa opened this Issue Dec 7, 2011 · 13 comments

Comments

Projects
None yet
5 participants
@schwa

schwa commented Dec 7, 2011

After testing CocoaPods it seems it builds an "umbrella" xcworkspace that is responsible for building the dependencies and the original Xcode project.

In my opinion this is not an ideal situation. It seems to me if you want Cocoa Pods to be accepted by the developer community you should be striving to work with the developer's existing workflow. Requiring a developer to dramatically change the way he/she works just to use CocoaPods isn't an acceptable solution in my opinion.

Reasons why this change could be a problem include (but are not limited to) breakage of pre-existing scripts and/or breaking of pre-existing workspace configurations.

To be honest the CocoaPods solution seems very ungraceful and a bit of a hack. Have other alternatives been explored?

@nolanw

This comment has been minimized.

Show comment
Hide comment
@nolanw

nolanw Dec 7, 2011

Contributor

One alternative that I suggested awhile back allowed us to directly add the CocoaPods-generated xcodeproj to an existing YourApp.xcodeproj.

Starting with Xcode 4, each .xcodeproj bundle has inside of it a project.xcworkspace bundle. It's a full-fledged workspace. The idea was to add CocoaPods.xcodeproj to this hidden xcworkspace. Then it just shows up under the YourApp project.

I forget why we decided not to try this out.

Contributor

nolanw commented Dec 7, 2011

One alternative that I suggested awhile back allowed us to directly add the CocoaPods-generated xcodeproj to an existing YourApp.xcodeproj.

Starting with Xcode 4, each .xcodeproj bundle has inside of it a project.xcworkspace bundle. It's a full-fledged workspace. The idea was to add CocoaPods.xcodeproj to this hidden xcworkspace. Then it just shows up under the YourApp project.

I forget why we decided not to try this out.

@schwa

This comment has been minimized.

Show comment
Hide comment
@schwa

schwa Dec 7, 2011

I'm quite happy with my "drag everything from the sub-project's Source directory and then modify any linker settings as needed".

This allows me full control over my project. there's no juggling of sub-projects or umbrella-workspaces. And if I want to change/fix code in the sub-project it's right in my current xcodeproj where i need it.

If CocoaPods supported that workflow (by actively modifying my xcodeproj) I'd be all for it.

Is that not an option?

schwa commented Dec 7, 2011

I'm quite happy with my "drag everything from the sub-project's Source directory and then modify any linker settings as needed".

This allows me full control over my project. there's no juggling of sub-projects or umbrella-workspaces. And if I want to change/fix code in the sub-project it's right in my current xcodeproj where i need it.

If CocoaPods supported that workflow (by actively modifying my xcodeproj) I'd be all for it.

Is that not an option?

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Dec 8, 2011

Member

@nolanw Yeah that might be an option for if one does prefer to keep the code and settings out of the app project, but has to deal with the ‘breakage of pre-existing scripts’ issue. I’m not sure anymore why we didn’t do it, maybe because it seems like an undocumented feature?

@schwa There’s no reason at all to not support it in the future, but the project is still young and I created something for myself in the first place. If someone were to create a patch to support both ways, I would apply it right away, but I have to work on other things first. I’ve planned this for 0.4, but I have no idea on the timeline. (I think I need to re-organize and re-schedule all tickets soon, so the exact milestone it’s planned for is subject to change.)

Regarding “breaking of pre-existing workspace configurations”, the creation of a workspace is optional and configuring a project can be done by following these steps, so that’s not a real issue.

Member

alloy commented Dec 8, 2011

@nolanw Yeah that might be an option for if one does prefer to keep the code and settings out of the app project, but has to deal with the ‘breakage of pre-existing scripts’ issue. I’m not sure anymore why we didn’t do it, maybe because it seems like an undocumented feature?

@schwa There’s no reason at all to not support it in the future, but the project is still young and I created something for myself in the first place. If someone were to create a patch to support both ways, I would apply it right away, but I have to work on other things first. I’ve planned this for 0.4, but I have no idea on the timeline. (I think I need to re-organize and re-schedule all tickets soon, so the exact milestone it’s planned for is subject to change.)

Regarding “breaking of pre-existing workspace configurations”, the creation of a workspace is optional and configuring a project can be done by following these steps, so that’s not a real issue.

@schwa

This comment has been minimized.

Show comment
Hide comment
@schwa

schwa Dec 8, 2011

If you're following those steps then what does CocoaPods actually bring to the table? Automatic updating? git submodules solve that - and don't have CocoaPods other's limitations/issues.

schwa commented Dec 8, 2011

If you're following those steps then what does CocoaPods actually bring to the table? Automatic updating? git submodules solve that - and don't have CocoaPods other's limitations/issues.

@nolanw

This comment has been minimized.

Show comment
Hide comment
@nolanw

nolanw Dec 8, 2011

Contributor

Dependency resolution?

Contributor

nolanw commented Dec 8, 2011

Dependency resolution?

@schwa

This comment has been minimized.

Show comment
Hide comment
@schwa

schwa Dec 8, 2011

Not much of a gain. In my experience very few Objective-C libraries have much in the way of dependencies and I think - unlike ruby gems/python modules Obj-C developers will strongly care what decencies are made a part of the app.

Really I think the key problem CocoaPods could solve is the pain involved in setting up projects with dependencies. Take that away and it leaves very little to benefit developers.

schwa commented Dec 8, 2011

Not much of a gain. In my experience very few Objective-C libraries have much in the way of dependencies and I think - unlike ruby gems/python modules Obj-C developers will strongly care what decencies are made a part of the app.

Really I think the key problem CocoaPods could solve is the pain involved in setting up projects with dependencies. Take that away and it leaves very little to benefit developers.

@nolanw

This comment has been minimized.

Show comment
Hide comment
@nolanw

nolanw Dec 8, 2011

Contributor

Not much of a gain right now, I agree. I wonder, though, whether Obj-C library developers have historically backed off of using dependencies (or just vendored them in to the library itself) because of how annoying it is to resolve those dependencies.

Contributor

nolanw commented Dec 8, 2011

Not much of a gain right now, I agree. I wonder, though, whether Obj-C library developers have historically backed off of using dependencies (or just vendored them in to the library itself) because of how annoying it is to resolve those dependencies.

@schwa

This comment has been minimized.

Show comment
Hide comment
@schwa

schwa Dec 8, 2011

I try and write stand alone open source libraries. It's a huge benefit to everyone.

Objective-C is dynamic and the linker can't dead-strip unused code from inked in libraries. So depending on a large library for just some useful utility classes/categories can be very wasteful. (not a big deal on the desktop, but possibly a huge deal on iOS).

I'd say most Cocoa libraries are standalone for good reasons. Avoiding dependency hell isn't necessarily one of them (but may contribute somewhat).

schwa commented Dec 8, 2011

I try and write stand alone open source libraries. It's a huge benefit to everyone.

Objective-C is dynamic and the linker can't dead-strip unused code from inked in libraries. So depending on a large library for just some useful utility classes/categories can be very wasteful. (not a big deal on the desktop, but possibly a huge deal on iOS).

I'd say most Cocoa libraries are standalone for good reasons. Avoiding dependency hell isn't necessarily one of them (but may contribute somewhat).

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Dec 8, 2011

Member

Yes, but a dependency does not necessarily have to be on a library for “just some useful utility classes/categories”.

Member

alloy commented Dec 8, 2011

Yes, but a dependency does not necessarily have to be on a library for “just some useful utility classes/categories”.

@romanr

This comment has been minimized.

Show comment
Hide comment
@romanr

romanr Jan 31, 2012

If we're talking about usefulness, for me CocoaPods seemed very useful not as dependency resolution but as subpackage installation tool. Configure pod config, and run the command. No need to clone git repos, drag files into project, etc.

But once I discovered that it requires to switch to using xcworkspace I couldn't' do it.
Clients and other developers working on same projects always work with .xcproject. It would be a lot of hassle to inform everyone that they need to open and work with workspace from now on. And workspace is supposed to be private thing - it's added to gitignore on most developers systems for a reason. So you have to do that as well, to make sure workspace is not blocked in git.
All that turns out into one big inconvenience. Disrupting the workflow is a deal breaker for many.

One more thing I am wondering about: Since workspace is intended for personal use and every developer on the project will have to use same workspace wouldn't that create a huge mess? Basically on the first push there will be a merge mess when two developers commit same workspace. Sharing the workspace would make project unusable. Or I am missing something?

If CocoaPods could modify xcproject so you could continue using just xcproject that would be a great and helpful tool!

romanr commented Jan 31, 2012

If we're talking about usefulness, for me CocoaPods seemed very useful not as dependency resolution but as subpackage installation tool. Configure pod config, and run the command. No need to clone git repos, drag files into project, etc.

But once I discovered that it requires to switch to using xcworkspace I couldn't' do it.
Clients and other developers working on same projects always work with .xcproject. It would be a lot of hassle to inform everyone that they need to open and work with workspace from now on. And workspace is supposed to be private thing - it's added to gitignore on most developers systems for a reason. So you have to do that as well, to make sure workspace is not blocked in git.
All that turns out into one big inconvenience. Disrupting the workflow is a deal breaker for many.

One more thing I am wondering about: Since workspace is intended for personal use and every developer on the project will have to use same workspace wouldn't that create a huge mess? Basically on the first push there will be a merge mess when two developers commit same workspace. Sharing the workspace would make project unusable. Or I am missing something?

If CocoaPods could modify xcproject so you could continue using just xcproject that would be a great and helpful tool!

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Mar 18, 2012

Member

And workspace is supposed to be private thing - it's added to gitignore on most developers systems for a reason. So you have to do that as well, to make sure workspace is not blocked in git.

@romanr That’s not entirely correct. Mostly when people add xcworkspace to their SCM ignore list, they mean the ones inside xcodeproj documents. A separate xcworkspace document, like the way the CocoaPods project integration module sets up, is intended to be treated just like a xcodeproj.

One more thing I am wondering about: Since workspace is intended for personal use and every developer on the project will have to use same workspace wouldn't that create a huge mess? Basically on the first push there will be a merge mess when two developers commit same workspace. Sharing the workspace would make project unusable. Or I am missing something?

No, because the workspace document is a really simple one which basically only holds references to the xcodeprojs it contains. E.g.:

% cat AFNetworking\ iOS\ Example.xcworkspace/contents.xcworkspacedata 
<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:AFNetworking iOS Example.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
</Workspace>

To conclude, what I think people should be ignoring is xcuserdata, not complete xcworkspace documents.

Member

alloy commented Mar 18, 2012

And workspace is supposed to be private thing - it's added to gitignore on most developers systems for a reason. So you have to do that as well, to make sure workspace is not blocked in git.

@romanr That’s not entirely correct. Mostly when people add xcworkspace to their SCM ignore list, they mean the ones inside xcodeproj documents. A separate xcworkspace document, like the way the CocoaPods project integration module sets up, is intended to be treated just like a xcodeproj.

One more thing I am wondering about: Since workspace is intended for personal use and every developer on the project will have to use same workspace wouldn't that create a huge mess? Basically on the first push there will be a merge mess when two developers commit same workspace. Sharing the workspace would make project unusable. Or I am missing something?

No, because the workspace document is a really simple one which basically only holds references to the xcodeprojs it contains. E.g.:

% cat AFNetworking\ iOS\ Example.xcworkspace/contents.xcworkspacedata 
<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:AFNetworking iOS Example.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
</Workspace>

To conclude, what I think people should be ignoring is xcuserdata, not complete xcworkspace documents.

@alloy

This comment has been minimized.

Show comment
Hide comment
@alloy

alloy Mar 18, 2012

Member

Moving this to 0.7, where I will experiment with adding Pods.xcodeproj as a subproject to the App.xcodeproj. I don’t ever see it happen that we’ll modify App.xcodeproj directly (besides the few setup changes), because that will just become unmaintainable. With a separate Pods.xcodeproj we can at least assume that we have total control over it without throwing away someone's manual work.

Member

alloy commented Mar 18, 2012

Moving this to 0.7, where I will experiment with adding Pods.xcodeproj as a subproject to the App.xcodeproj. I don’t ever see it happen that we’ll modify App.xcodeproj directly (besides the few setup changes), because that will just become unmaintainable. With a separate Pods.xcodeproj we can at least assume that we have total control over it without throwing away someone's manual work.

@fabiopelosin fabiopelosin referenced this issue Mar 9, 2013

Closed

Isolate Pods in dedicated targets #841

1 of 3 tasks complete
@fabiopelosin

This comment has been minimized.

Show comment
Hide comment
@fabiopelosin

fabiopelosin Apr 9, 2013

Member

Moving to #841, which would allow to install to add the Pods project to the client one with non integrating installations.

Member

fabiopelosin commented Apr 9, 2013

Moving to #841, which would allow to install to add the Pods project to the client one with non integrating installations.

jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013

Merge pull request #94 from brunow/master
ITWLoadingPanel version 1.0.1

fabiopelosin added a commit that referenced this issue Oct 25, 2014

Merge pull request #94 from CocoaPods/feature-linter-keys-check
[Spec::Linter] Initial implementation for checking the keys of the attributes hash
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment