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

Clean up Podfile syntax #840

Closed
fabiopelosin opened this Issue Mar 9, 2013 · 22 comments

Comments

Projects
None yet
@fabiopelosin
Member

fabiopelosin commented Mar 9, 2013

Background

Note: This text will be updated to reflect the most recent proposal

Currently CocoaPods:

  • Skips target definitions without dependencies as the user might not want the implicit root target definition (which automatically links with the first target) and there is no other way to prevent its integration.
  • Marks a target as exclusive if it has a different platform from the parent not inheriting any dependency.
  • Doesn't have a way to specify what should be inherited from the parent target definition (nothing, only the headers, the dependencies). This is evident in the tests target which currently need to be marked as exclusive, however this set up only works because CocoaPods makes the headers of all targets visible (exactly for this reason).
  • Doesn't allow to specify that a target should not be integrated in the Podfile. It is only possible to specify that whole Podfile should not be integrated (i.e. no workspace) with a command line option.

Proposal

  • Add a new abstract_target! attribute to the target definition.
    • Skip the installation of the implicit root target definition if it doesn't have any dependency (temporary see below).
    • Otherwise never skip the installation of a target unless marked abstract.
  • Add a new do_not_integrate! root attribute which would replace the command line option (--no-integrate of pod install and pod update).
  • Inherit the compatible dependencies from the parent target definition if the platforms do not match.
  • Add a new inherit attribute to the target definition which would support 3 values (true, false, :headers).
    • Phase out the exclusive option of the target definition.
  • Drop any form of integration of the implicit target definition by CP 1.0. Adding a warning immediately.
  • Drop the options parameter used for new target definitions (the has used after the name and before the block) in favor of statements inside the block.
    • This would accelerate the phasing out of the exclusive option.
  • Deprecate the link_with attribute. Every integrated target should be identified by the name of the target definition common dependencies can be declared in dedicated targets. This would not only simplify the DSL but also the implementation of the CP analyzer and user project integrator.

Points which require Feedback

  • The name of the abstract_target! and of the do_not_integrate!
  • Wether inheritance by nesting targets definitions should be dropped for an attribute (inherits_from, se example below).

Podfile examples

Headers only inheritance

Note that By CocoaPods 1.0 the abstract_target! call can be dropped from the root as it will become the default behaviour.

abstract_target!
pod 'CocoaAsyncSocket', '0.0.1'
pod 'CocoaLumberjack', '>=1.6'

target 'App_1'
  # deps
end

target 'App_2'
  # deps
end

Abstract targets
target 'MacApp'
  pod 'AFNetworking'

  target 'MacAppTests' do
     use_headers_of_parent
     # dependencies
  end
end

Alternative headers only inheritance

In this scenario nesting would be disabled.

target 'MacApp'
  pod 'AFNetworking'
end

target 'MacAppTests' do
  use_headers_of 'MacApp' 
  # use_headers_of 'MacApp_1', 'MacApp_2'
  # dependencies
end

Multi platform inheritance
abstract_target!
pod 'CocoaAsyncSocket', '0.0.1'
pod 'CocoaLumberjack', '>=1.6'

target 'iOSApp'
  platform :ios
  # deps
end

target 'MacApp'
  platform :osx 
  # deps
end
@fabiopelosin

This comment has been minimized.

Member

fabiopelosin commented Apr 2, 2013

Regarding #738, CP should improve the logic to handle the implicitly created default target if empty.

@fabiopelosin

This comment has been minimized.

Member

fabiopelosin commented Dec 11, 2013

Another idea:

workspace "NAME.xcworkspace" # optional

project "NAME.project" do # optional defaults to auto-detection if only one project is available 
  # Project wide dependencies
  pod "A"
  pod "B"

  target "TARGET-A" do
    pod "C"
    configuration "Debug" do 
      incorporate "ABSTRACT-TARGET"
      pod "D"
    end
    configuration "Release" do 
      pod "E"
    end
  end

  target "TARGET-A-TESTS" do
      pod "F"
      incorporate_headers "TARGET-A"
  end
end

abstract_target ''ABSTRACT-TARGET" do
  pod "Z"
end

Features:

  • Clear and consistent inheritance based on granularity of the usage of the dependency.
  • Easy way to declare abstract targets.
  • Easy way to incorporate the dependencies of one level – project/target/configuration – in another one.
  • Support for incorporating the headers only.
  • Support for build configurations.

Another idea potentially alternative would be to have an omit directive which could be alternative or could complement – yeah the upcoming name could be improved – incorporate.

@rivera-ernesto

This comment has been minimized.

Contributor

rivera-ernesto commented Dec 12, 2013

So in the future YML will only be for podspecs?

@fabiopelosin

This comment has been minimized.

Member

fabiopelosin commented Dec 13, 2013

@rivera-ernesto There hasn't been much talk in this regard. I'm favorable for a machine editable Podfile (and as you may know, according to your comment, CocoaPods already supports it). However even with that support I don't see us phasing out the ruby format anytime soon.

Moreover the DSL mirrors (although imperfectly) the underlying data structure, and so this discussion is beneficial for YML/JSON Podfiles.

@rivera-ernesto

This comment has been minimized.

Contributor

rivera-ernesto commented Dec 13, 2013

Moreover the DSL mirrors (although imperfectly) the underlying data structure, and so this discussion is beneficial for YML/JSON Podfiles.

I see.

I guess there are many non-backward compatible changes that you would like to make, and I think that having two formats, YML and Ruby, could help:

  • YML: the new standard with new syntax and improvements, non-backward compatible.
  • Ruby: legacy mode, projects still build and run, but projects should move to the new format and syntax to get cool new features.
@alloy

This comment has been minimized.

Member

alloy commented Dec 13, 2013

Ruby: legacy mode, projects still build and run, but projects should move to the new format and syntax to get cool new features.

The Ruby format will not be a legacy mode, it will be fully supported and the preferable way if you need to perform extra work that requires a turing complete language.

@fabiopelosin

This comment has been minimized.

Member

fabiopelosin commented Dec 13, 2013

The Ruby format will not be a legacy mode, it will be fully supported and the preferable way if you need to perform extra work that requires a turing complete language.

I think that it i too early to make our mind on this. I would just like to point out that I consider the Podfile data and if stored in a YAML/JSON based format you can use any turing complete language to edit it. Hooks are another matter but we could add support for them allowing to specify a Ruby source file if the plug-in architecture doesn't prove to be flexible enough to handle custom cases (we need hooks for the plugins though).

@orta

This comment has been minimized.

Member

orta commented Nov 17, 2014

Actually I totally agree and am glad that you decided to depreciate and drop the "implicit first target" thingy, as this makes things confusing.

I disagree with this, every Podfile I build uses the implicit target. They generally look like

pod "x"
pod "y"

target "YYYTests", :exclusive => true do
    pod 'z'
end

This seems totally reasonable from the DSL perspective, x, y go in all targets as they're root, then z only goes on the tests target.

@segiddins

This comment has been minimized.

Member

segiddins commented Nov 17, 2014

The behavior we're changing to will still allow for not specifying a target, but pods there will link with every target by default, not just the first.

-Samuel E. Giddins

On Nov 17, 2014, at 6:05 AM, Orta notifications@github.com wrote:

Actually I totally agree and am glad that you decided to depreciate and drop the "implicit first target" thingy, as this makes things confusing.

I disagree with this, every Podfile I build uses the implicit target. They generally look like

pod "x"
pod "y"

target "YYYTests", :exclusive => true do
pod 'z'
end
This seems totally reasonable from the DSL perspective, x, y go in all targets as they're root, then z only goes on the tests target.


Reply to this email directly or view it on GitHub.

@AliSoftware

This comment has been minimized.

Contributor

AliSoftware commented Nov 18, 2014

Regarding the new Podfile DSL, I believe that we can get rid of the platform attribute, as I guess it can be deducted by CocoaPods/Xcodeproj automatically, right?

Of course, we would have to ensure that Molinillo takes the right deployment_target for its dependency resolution, depending on for which target it tries to do the resolution.

@segiddins

This comment has been minimized.

Member

segiddins commented Nov 18, 2014

The platform attribute will stay for those who choose the do_not_integrate option.

-Samuel E. Giddins

On Nov 18, 2014, at 5:31 AM, AliSoftware notifications@github.com wrote:

Regarding the new Podfile DSL, I believe that we can get rid of the platform attribute, as I guess it can be deducted by CocoaPods/Xcodeproj automatically, right?

Of course, we would have to ensure that Molinillo takes the right deployment_target for its dependency resolution, depending on for which target it tries to do the resolution.


Reply to this email directly or view it on GitHub.

@orta

This comment has been minimized.

Member

orta commented Jan 20, 2015

bwahah, you can't escape.

@jcampbell05

This comment has been minimized.

Collaborator

jcampbell05 commented Dec 10, 2015

Hoe much of this is achieved ?

@kylef

This comment has been minimized.

Contributor

kylef commented Dec 10, 2015

@jcampbell05 There is a WIP pull request at #4644

@segiddins segiddins referenced this issue Dec 28, 2015

Merged

Podfile Refactor #4644

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