Repository navigation
Let the Podfile be dynamically created #9827
Description
Activity
- added this to the milestone
on May 5, 2017 I'm not sure if i'm interpreting this correctly but I would think that it is a bad situation to not have control of the podfile as a developer. I can see cases (mentioned as hybrid apps in #9763) where we might absolutely want to build something native that is not a plugin and requires a pod. I don't think it should be tied to plugin development, unless you're implying that hybrid applications may not be possible? You can use platform messaging in the application to communicate from the native code without using a "formal" plugin. Does that count?
While we're on the subject, I think that updating or installing pods should be a manual step. I wouldn't expect the
runcommand to do that for me every time. I'd prefer to have control over that part of the build process.Hybrid apps are definitely possible now and in the future. This issue is just a small optimization on the Podfile management. Let me elaborate:
Today
- Podfiles with our plugin management scripts are created during
flutter createwith no other CocoaPods artifacts. Podfile goes into source control at this point. - Running
pod installmanually on a fresh project is possible (after setting some environment variables). Though it creates a whole bunch of hookups in the iOS project that don't do anything - Once user starts using plugins in pubspec, flutter build/run will automatically run
pod install - Without using plugins, users can insert custom pod instructions in the existing Podfile between the
target 'Runner' dolines, then manually invokepod install.flutter build/runwon't invokepod installsince there are no plugins. - Users can have manual entries in the Podfile and also use plugins in pubspec.
flutter build/runrunspod install.pod installcan also be run manually.
My proposal
- Don't create any Podfiles during
flutter create - Manual
pod installon a fresh project not possible (since there's nothing to install) - When user uses plugins for the first time without a user custom Podfile, flutter tools will create a Podfile with today's plugin scripts in a versioned, annotated section of the Podfile. Podfile goes into source control at this point. Running
flutter build/runautomatically runspod install - Users can create a Podfile and run
pod installwithout using plugins. Without plugins, flutter tools would be entirely agnostic about CocoaPods - If the user adds manual entries in the Podfile outside the generated, annotated section after using plugins or starts using plugins, after having inserted custom entries in the Podfile, flutter tools will manage the annotated section only. In this hybrid case, flutter tools knows if there are user entries and lets the user run
pod installmanually only.
Implications
- If we update the plugin script in the future, we can still update it in user projects' hybrid Podfiles and do in-place swaps automatically since the generated portion is annotated.
- If the user starts or stops using plugins, we can cleanly add or remove the plugins script around the user's custom pod instructions
- flutter tools can know if it's operating in [no cocoapods mode, user custom pod mode, flutter plugins mode, or hybrid mode] and have different behaviours (such as whether to run
pod installautomatically or not. Today, we only know about [flutter plugins mode, no flutter plugins mode]. - Start projects clean with no CocoaPods anywhere. Though as Eric pointed out, this is probably not important.
I think your desired behaviours are already achievable today if I understand correctly. This is just for setting us up to cleanly handle some edge cases that might arise in the future with projects that are
flutter created today.- Podfiles with our plugin management scripts are created during
I assume you guys aren't actually using custom CocoaPods or plugins currently in your project right?
If so,
- Future
flutter created projects won't have this problem - For you current projects, you can just remove all CocoaPods related things in the ios folder except
Podfile(until this issues is resolved). That is, the Podfile.lock, the Pods folder, everything that mentions 'pod' in Runner.xcodeproj/project.pbxproj. When you start using plugins again, everything will safely regenerate.
Let me know if that's what you were facing. Feel free to assign issues directly to me in GitHub if you encounter any other issues.
- Future
I believe that's all we'll need, thanks for getting back to me! This current solution is manageable.
@szakarias @jakobr-google would this solution resolve the issue you were mentioning?
Hopefully, if done right. The problem we're having right now is that manually running
pod installdoesn't work, because the project has custom configuration that doesn't include the .xcconfig files generated by CocoaPods. We specifically only include those if the project uses plugins.Removing the pods .xcconfigs when there are no plugins is what's biting us when removing the last plugin from a project -- the project is still CocoaPods enabled, but we're now not including the pods .xcconfig, so it won't build.
If the proposed solution here takes care of wiring up the pods .xcconfig correctly when necessary (ie. either when using plugins or other pods, or just always if they exist!), we should be good.
Concretely to see the issue:
flutter create my_appEdit
Podfileby adding a pod, for instance# Pods for Runner pod 'MaterialControls'Run
pod installby runningFLUTTER_FRAMEWORK_DIR=<path to flutter>/bin/cache/artifacts/engine/ios pod installNow
flutter runfails with this messagediff: /Podfile.lock: No such file or directory diff: /Manifest.lock: No such file or directory error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation. Could not build the application for the simulator.Reacted by David Amey#9827 (comment) is indeed an issue.
I think if we were generating and managing the contents of the Podfile (such that we can compare the actual contents vs our template), we'd edit https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/ios/mac.dart#L162
such that _runPodInstall still gates on hasFlutterPlugin but updateXcodeGeneratedProperties(hasPlugins would be renamed attachPodXcconfig and would gate on _isFlutterPluginUnmodifiedPodfile(podfile) instead of hasFlutterPlugin.To summarise, we should have the following use cases:
A. Flutter app contains no pods or plugins
B. Flutter app contains one or more plugins, but no pods
C. Flutter app contains no plugins, but one or more pods (e.g., a hybrid app using an iOS widget distributed on cocoapods)
D. Flutter app has one or more plugins as well as one or more podsIn case A the developer should not need Cocoapads installed, and no pod file should be present. I believe this has already been completed.
In case B, Cocoapods is required, but the developer should not need to edit the Podfile. We call pod install as part of build. I believe this has already been completed.
In case C, Cocoapods is required, and the developer owns creating and maintaining the Podfile, but we should call pod install as part of build. This is not working currently.
In case D, Cocoapods is required, and the developer still owns creating and maintaining the Podfile; practically likely by copying our Podfile template, and adding their own content under
# Pods for Runner? We call pod install as part of build.10 remaining items
@xster I have lost track a bit, can you comment on where are are wrt. supporting use cases A, B, C, and D that I listed in #9827 (comment) ?
Since this doesn't seem like a new user blocker, moving to next milestone.
I don't think we can do that, people add their own Pods, we don't really own that file (seen a lot of bug related to OneSignal, for example)... It would be great if we had the
flutter migratefeature to sha the files and know if they have been edited from the template.This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked and limited conversation to collaborators
on Apr 5, 2020
Extracted from #9763
Let the Podfile be managed by the flutter tool at build time rather than as an artifact of
flutter create. This lets us version Podfiles created by old invocations offlutter createas well as handle upgrades of hybrid Podfiles that users have altered to include their own pod dependencies. Probably by tagging the file with markers such asThis way, users also can't run
pod installin the iOS folder before using plugins or editing his own Podfile and get a strange error.With this, we can also
pod deintegratethe project if no plugins are left and there are no entries outside our marked generated lines.