Repository navigation
A Flutter app's Podfile.lock should be versionable #9502
Description
Steps to Reproduce
Create a new app and build it for the simulator:
flutter create myapp
cd myapp
<add plugin dependency to pubspec.yaml>
flutter run -d i
git init
git add .
git commit
You've just committed a Podfile.lock file that contains local paths to your plugins and Flutter framework, e.g.
EXTERNAL SOURCES:
Flutter:
:path: /Users/jackson/git/flutter/bin/cache/artifacts/engine/ios
Everyone who builds the app will end up with a different Podfile.lock, and won't be sure whether to check in their version. Unfortunately, adding Podfile.lock to .gitignore is not recommended by the CocoaPods team because it makes builds non-reproducible.
I think we can address this by making some changes to the template app's Podfile.
Instead of having .flutter-plugins be a file, have it be a directory that contains contains a symbolic link called Flutter pointing to the Flutter framework directory, as well as symbolic links to the directories of all the plugin Pods.
Now the Flutter section of the Podfile looks like this:
# Flutter Pods
if Dir.exists? '../.flutter-plugins'
Dir.foreach('../.flutter-plugins') { |name|
next if name == '.' or name == '..'
pod name, :path => "../.flutter-plugins/#{name}/ios"
}
end
Benefits
- Less boilerplate code in the Podfile
- Going to the
ios/directory and runningpod installmanually will actually work (after the first Flutter iOS build) instead of complaining that theFLUTTER_FRAMEWORK_DIRenvironment variable is not set. - The
Podfile.lockwill be the same for everyone. It will look like this:
DEPENDENCIES:
- firebase_database (from `../.flutter-plugins/firebase_database/ios`)
- firebase_storage (from `../.flutter-plugins/firebase_storage/ios`)
- Flutter (from `../.flutter-plugins/Flutter/ios`)
- google_sign_in (from `../.flutter-plugins/google_sign_in/ios`)
- image_picker (from `../.flutter-plugins/image_picker/ios`)
EXTERNAL SOURCES:
firebase_database:
:path: ../.flutter-plugins/firebase_database/ios
firebase_storage:
:path: ../.flutter-plugins/firebase_storage/ios
Flutter:
:path: ../.flutter-plugins/Flutter/ios
google_sign_in:
:path: ../.flutter-plugins/google_sign_in/ios
image_picker:
:path: ../.flutter-plugins/image_picker/ios
...
While we are at it, I think we should add Pods/ to ios/.gitignore, which is allowed according to the Cocoapods team. But that's more a matter of taste since (at least in theory) the contents of that directory should be the same for every developer as long as their Flutter engines are in sync.
Activity
collinjackson commentedon Apr 20, 2017
@goderbauer @jakobr-google @mit-mit @mravn-google
jakobr-google commentedon Apr 21, 2017
I like the idea in principle, but the Dart core team just spent a considerable amount of time and effort to move away from using symlinks for packages. We should make sure we understand their reasons before deciding.
mit-mit commentedon Apr 24, 2017
Could the path use a FLUTTER_SDK_HOME variable or something like that?
collinjackson commentedon Apr 24, 2017
I don't believe that Podfile.lock supports template expansion of environment variables.
Because flutter_tools requires a Mac to build Flutter iOS apps (and probably always will), I think it is safe to assume that symlinks work when flutter_tools is running on a Mac (and probably Linux too). Android builds on Windows can do something different; since .flutter-plugins is included in .gitignore, it should be ok to have it work differently on different platforms.
We could have the logic for reading .flutter-plugins and turning it into symlinks live in the template app's Podfile, but since the Podfile is user-editable we might want to make it as simple as possible and push that work into flutter_tools.
@jakobr-google, I think we'll be in the same office tomorrow, happy to discuss live.
Related bug: #9299
jakobr-google commentedon Apr 25, 2017
The agreed solution is to add a .gitignore'd directory in ios/ containing symlinks to the pods, and only generate this when building for iOS (assuming that will only happen on platforms with sane symlinks).
We also keep the current .flutter-plugins file to avoid having to change Android (and older iOS) projects.
eseidelGoogle commentedon Apr 25, 2017
@jakobr-google Is this something you are willing to do for M2? Currently targeting May 5th for M2.
jakobr-google commentedon Apr 25, 2017
Looking at it right now.
eseidelGoogle commentedon May 2, 2017
@xster was working in this space, did you solve this too?
eseidelGoogle commentedon May 2, 2017
Regardless, M2 ends this Friday, please let us know if you plan to hit that. :)
xster commentedon May 2, 2017
I'm only involved very tangentially. I don't have a strong opinion but I really like Collin's proposal. (#9502 (comment) sounds functionally equivalent AFAICT?)
The #9580 cluster somewhat alleviates this because the majority of users won't end up changing this file until they 1- start using pub plugins, 2- install pod, 3- setup pod, 4- build flutter with pod.
If I understand right, if user A flutter creates, never uses our plugin system and just goes into the ios folder and manually
pod installs, checks in the various non-gitignored files, and user B checks out the same updated project but doesn't have cocoapods installed (and doesn't have the pods directory), user B can still flutter build ios?mit-mit commentedon May 4, 2017
I think thing this is an appealing idea, but I think it may be too risky to change this for I/O. Can we move this to the May milestone? cc @eseidelGoogle.
jakobr-google commentedon May 4, 2017
I ran into issues with the symlinks approach that I haven't been able to resolve yet, so this won't make it for I/O.
eseidelGoogle commentedon May 4, 2017
@mit-mit you should always feel empowered to move bugs.
mit-mit commentedon Nov 23, 2017
Unassigning as Jakob is currently busy with other tasks
collinjackson commentedon Dec 8, 2017
/cc @xster
mit-mit commentedon Dec 27, 2017
Having spend the last week writing a small demo app with a few others, I can confirm that this issue is very, very irritating... Keeping in milestone 3.
@xster given this is iOS specific, is this something you can help with?
xster commentedon Dec 27, 2017
I added it to my list. I'll likely get to it in February
github-actions commentedon Sep 3, 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.