Closed yvbeek closed 4 years ago
Thank you for sharing. Minor note I see you are using Abc
, we are using Source
.
Your discussion relates to dependency management of your module (i.e. Pod) -- and you are managing external cocoapods dependencies using cocoapods.
It is also possible to consider dependency management of the test project. For example, the test program may use a UI testing framework. The test program depends on that, and your pod does not depend on that.
In terms of the recommended change to this project, are you suggesting that someone using swift3-module-template may run the configurator and then edit their vendored version of https://github.com/fulldecent/swift3-module-template/blob/master/__PROJECT_NAME__/__PROJECT_NAME__.podspec (and run pod update
) to add the dependencies they want?
@fulldecent Thank you for your feedback!
Abc
is __PROJECT_NAME__
in this example. I've moved the Source folder into the __PROJECT_NAME__
folder so that it better matches Xcode's default structure. I've updated my first post to give a bit more information on the folder structure.
The Podfile describes the pods used in the Abc
, AbcTests
and iOS Example
projects.
You can see in my example that the iOS Example
is only using the Abc
pod, but it is perfectly fine to add more pod references. Anything that you specify in the Podfile within a target will only be used by that target.
In terms of changes I recommend the following:
Source
into __PROJECT_NAME__
Resources
into __PROJECT_NAME__
Resources
in Tests
Resources
in iOS Example
__PROJECT_NAME__Tests
, e.g. Tests
becomes AbcTests
pod install
after the configurator is doneTo make it easier for the developer to keep the Podfile and the podspec in sync we could add a post-install script to the Podfile that rewrites the dependencies in the podspec.
I've also noticed a small issue that the date generated in the source files doesn't match the date format of my Xcode. Feb 9, 2017
should be 2/9/17
.
Thank you for the detailed recommendations and usable action plan!
Items 1, 2, 5, 6. Regarding folder names (Source/
folder, etc.), I am closely following the implementation of AlamoFire. This choice is also documented in the Recipe. If AlamoFire changes (and they are not shy about changing things) then I will follow their lead. Or if Swift Package Manager begins officially supporting iOS projects and has a conflicting folder layout, then I would adopt that. Xcode's default file layout should be respected, but at this time I trust AlamoFire more than Xcode in terms of project layout for a Swift module.
Items 3, 4. 👍 This is good and we should do it. I would like to find a decent example to add to this project. Because "hello world" is better than silence.
Resources
in Tests
Tests/Resources
and make a test case that uses it somehowResources
in iOS Example
iOS Example/Resources
and use it somehow in the example appItems 7, 8. 👍 This introduces a dependency of this project onto CocoaPods. I want this project to support "any Swift 3 module that you want other people to include in their projects". Since not every Swift 3 module should be on CocoaPods then therefore this project should not depend on CocoaPods. Many people (myself included) WILL have CocoaPods installed and want to manage a dependency using CP. Therefore I am thinking:
Example
that people may want to usemaster
into cocoapods-for-dependencies
pod update
In doing these things, let's consider the pods that https://github.com/CocoaPods/pod-template uses by default. Because our cocoapods-for-dependencies
branch will be a candidate for replacing the pod-template
project. P.S. I am an editor on the pod-template
project.
I've used this template with pod dependencies, and my Podfile looks like this(without touching Project structure):
-----------------Podfile------------------ platform :ios, '8.0' use_frameworks!
source 'https://github.com/CocoaPods/Specs.git'
workspace '__PROJECT_NAME__'
target 'iOS Example' do project 'iOS Example/iOS Example' pod '__PROJECT_NAME__', :path => '.' end
target 'PROJECT_NAME' do project 'PROJECT_NAME'
&# dependencies here
target '__PROJECT_NAME__Tests' end
Over time I've made a few changes, you can have a look at this project: https://github.com/Building42/Telegraph
The set-up works well and should be compatible with Swift Package Manager.
I'd like to integrate my framework without CocoaPods because it is sometimes really error-prone that you have to do a pod update
when you add files.
The Swift 5 module template is updated as of last week. The iOS project is in a separate folder.
With this update, it is not allowed that your module depend on other CocoaPods. Because Swift Package Manager cannot build that. You still can have your example app depend on Pods.
I believe there is no special setup necessary at all. Just use CocoaPods on the example app. This would make it noteworthy. But no code would be needed in this repo to do it.
If that is correct I would be inclined to close this issue as resolved by the latest release.
Closing for now. Please do comment or reopen if I have misinterpreted this.
This template is great, it should be the default of
pod lib create
as soon as possible. The current template provided by CocoaPods is very confusing.I've changed the project generated by the swift3-module-template a bit so that it is easier to create a pod that has dependencies on other pods (see issue https://github.com/fulldecent/swift3-module-template/issues/8). The podfile in the root of my project looks like this:
It will create one workspace that contains three projects:
The pod spec looks like this:
When you add or remove files from your pod, just run
pod update
and the updated pod will be used.My folder looks like this:
What do you guys think?