Repository navigation
Flutter create's git clone doesn't build ios #9763
Description
I think we created a missing edge case with #9464/#9085 for Mac wrt cocoapods
- Check out flutter 7a57d37
- brew uninstall cocoapods
- flutter create project A
- that project builds ok
- git init, git add ., git ci -am
- git clone project A into project B
- try to build ios in project B
That project won't build because the Pod directory generated in project A isn't checked in by default. This creates a problem for team development since the references to Pod in Pod's parent directory is still present and building causes
diff: /../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.
Perhaps we should make the flutter create's general dependency on cocoapods reduced until the user needs to use cocoapods.
Activity
[-]Flutter create's git clone doesn't build[/-][+]Flutter create's git clone doesn't build ios[/+]xster commentedon May 3, 2017
cc @mit-mit @jakobr-google @cbracken
Sorry for messing around cocoapods more. I think we're getting closer and closer though.
Just trying to explicitly list out a few assumed criteria to make the solution finding easier.
flutter runshould fail if the initial cocoapods podspec repo hasn't been cloned instead of doing a 20 minute clone #9580To satisfy all of the above, I tentatively propose (please violently scrutinize, I'm not sure I caught all the details)
flutter createdoesn't include any traces of cocoapods. Not in ios/Pods and not ios/Podfile, ios/Podfile.lock, ios/Runner.xcodeproj/project.pbxproj etc either.pod deintegratewhen users remove all pluginscbracken commentedon May 3, 2017
One exception I think would be acceptable is when a project changes state from no pod deps to having pod deps, I'd be fine with checking in the additional build phases. Otherwise we end up effectively having to
pod install; buildl; pod deintegrateon each run.cbracken commentedon May 3, 2017
I like this from the position of boilerplate reduction. To be clear, I think having the
PodsandFrameworksfolders in thexcworkspaceis probably fine though.cbracken commentedon May 3, 2017
For the base case, this seems really nice. One potential edge-case to consider: are there cases where a user might add CocoaPods without it being specific to a Flutter plugin?
mit-mit commentedon May 3, 2017
Yes, hybrid apps. I think even the flutter_view sample does that.
cbracken commentedon May 3, 2017
One more point re:
The vast majority of real-world apps will depend on pods, so I don't think our goal should necessarily be to avoid any mention of them in the default project.
If we're going to assume all real-world projects rely on plugins, then it's probably fair to require Cocoapods to be installed for real-world projects. The main reason it'd be really nice to have the default initial project (and some of our examples) not require Cocoapods is to allow people new to the framework to try it out with low overhead and do some quick experimenting without 100s of MB of download first.
I like the idea from the perspective of boilerplate reduction -- but perhaps that's a separate bug. On that end of things, I think the requirements are:
.gitignored should be meaningful/editable to the developer. Everything else should be generated on the fly and not checked in.fluter createthengit add ., push to a repo, blow everything away, clone it back and it still works.xster commentedon May 3, 2017
I agree with #9763 (comment)
#9763 (comment), you meant just the folder references right? Not the actual folder on disk (in case of Pods)
#9763 (comment) in those cases, users have to likely modify the Podfile itself. I think we should defer the running of
pod installto the user in those cases. i.e. only automatically runpod install/deintegrateinflutter build iosonly if the Podfile's hash matches our version.cbracken commentedon May 3, 2017
Yep.
xster commentedon May 3, 2017
wrt
I just tested it. We're actually not that far from it at all.
I tried
flutter create. Then go into the project and delete all traces of cocoapods. Everything builds fine. Then add url_launcher: ^0.3.0 to the pubspec, install cocoapods and run flutter build ios.The only things we're missing is
jakobr-google commentedon May 4, 2017
I'm not sure if it's a good idea to de-integrate pods if we go from having plugins to not having plugins. If we want to, then yes, we can only do it if the user hasn't modified the Podfile. Does
pod deintegrateblow away the xcworkspace?You'll also have to handle the case where users have manually added a Podfile, and some time later start using plugins. You'll need to have a way to add our plugin boilerplate code to their existing Podfile - maybe just detect this situation and tell them what to do manually (they must know how, since they've already added their own Podfile).
And I'd prefer always running
pod installif there is a Podfile (assuming that it now only exists if the project is using pods, either directly or through plugins). And make it an error to not have CocoaPods installed if there is a Podfile - maybe only if the app uses plugins.Since we now only run
pod installif someone has added a Podfile, we could also automatically runpod setupas a separate long-running step before invokingpod installif we detect the repo hasn't been initialized yet. That'd be nice of us, and still make it apparent what's going on.cbracken commentedon May 4, 2017
Agreed. Less conditional execution means simpler code and testing and a more predictable experience for developers.
I really like the idea of trying to detect that
pod setupneeds to be run, but from a developer experience point of view, I'd much rather we bail out with an error message indicating thatpod setupneeds to be run and that it can be a time-consuming step, rather than opting me into a 10-15 minute step (my experience on a 50Mbps connection) that I didn't explicitly know I was going to get. Developers who want to run it immediately can do so. Anyone working from a non-ideal environment or without 15 mins to spare, can defer till later.xster commentedon May 5, 2017
Closing this bug since its primary issue is fixed. Will open children bugs for other minor issues discovered during investigation.
Whether to also generate Podfile via dart and not check in a static Podfile
I feel a bit more strongly about this one. I think we should 'manage' the contents of a Podfile from flutter tools directly. This will 'permit' the injection of flutter's Podfile script in a hybrid case after a user already has a Podfile or allow 'versioning' of Podfiles as we find bugs or add improvements, we can 'update' and existing Podfile which may have hybrid user entries without deleting the whole file. This way, we don't need to create a Podfile in the initial
flutter createeither.Whether to automatically trigger
pod installon pubspec plugins or on Podfile presenceUmm, I don't really have a strong opinion on this. I'm slightly leaning on the side of, if the user made any manual changes to Podfile himself, he should probably manage his own executions of
pod install. If there is also usage of pubspec plugins, we can of course warn/remind him to keep runningpod installmanually to keep things up to date.Whether to clean with
pod deintegrateif no plugins are leftI think this one's probably pretty simple especially if we manage the Podfile via dart. If it's a vanilla Podfile purely generated by the flutter tools, we can
pod deintegrateand clean everything up. If the user has his own entries, don't.Whether to automatically
pod setupI think from #9580, we shouldn't. It takes a really long time and consumes a lot of bandwidth and disk space. We should let the user install it themselves.
github-actions commentedon Sep 5, 2021
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.