The iOS release is blocked

[teolemon]

What

• The iOS release is blocked

  
  Analyzing dependencies
  [!] CocoaPods could not find compatible versions for pod "GoogleMLKit/BarcodeScanning":
  In snapshot (Podfile.lock):
  GoogleMLKit/BarcodeScanning (= 2.6.0, ~> 2.6.0)
  
  In Podfile:
  google_mlkit_barcode_scanning (from `.symlinks/plugins/google_mlkit_barcode_scanning/ios`) was resolved to 0.5.0, which depends on
    GoogleMLKit/BarcodeScanning (~> 3.2.0)

You have either:

• changed the constraints of dependency GoogleMLKit/BarcodeScanning inside your development pod google_mlkit_barcode_scanning. You should run pod update GoogleMLKit/BarcodeScanning to apply changes you've made.

[monsieurtanuki]

Already detected by @M123-dev in https://github.com/openfoodfacts/smooth-app/pull/3793#issuecomment-1478495986

Basically, there are discrepancies in pods between the mobile_scanner package that we know use for MLKit in flutter 3.7, and the more recent "awesome+mlkit" that @M123-dev introduced in #3790.

A quick fix would be to get rid of "awesome+mlkit" ("I was there first!"), or at least to neutralize its mlkit package (if possible?) (just for ios?).

[M123-dev]

I just did some further research, there are multiple stack overflow question on this

https://stackoverflow.com/questions/73454960/cocoapods-could-not-find-compatible-versions-for-pod-changed-the-constraints-o

https://stackoverflow.com/questions/70773323/is-there-a-way-that-i-can-fix-this-cocoapods-related-error

https://stackoverflow.com/questions/64443888/flutter-cocoapodss-specs-repository-is-too-out-of-date-to-satisfy-dependencies

They all suggest some kind of:

flutter clean
cd ios 
rm -rf Pods
rm Podfile.lock
flutter pub get
pod install

Or something with the pods' repository which needs to be updated but I did not understand this completely

[Edited the commands to shell syntax]

[monsieurtanuki]

@M123-dev I don't think it's a matter of version upgrade, but of version incompatibilities. That said, I hate apple, I don't care about CI/CD and I don't even know what a pod is, that's my level of expertise in the current issue!

[juliansteenbakker]

Hi all, fyi, i just updated the GoogleMLKit/BarcodeScanning dependency to 4.0.0 in the master code of mobile_scanner, which will be released somewhere in the coming days.

[monsieurtanuki]

Thank you @juliansteenbakker! Well, anyway we (temporarily) currently use directly master so we are already impacted ;)

[juliansteenbakker]

This seems fixed now with the 3.2.0 version of mlkit.

[monsieurtanuki]

Thank you @juliansteenbakker for your help!

That said, we agree we cannot stay too long with your dedicated 3.2.0 branch. On the other hand, most developers here do not use mac, therefore I expect glitches every time a "windows" developer updates the mlkit version, as the ios Podfile.lock (or whatever that is) may be out of sync.

Would you recommend us to include a clean refresh like that in our ios build?

cd ios 
rm -rf Pods
rm Podfile.lock
flutter pub get
pod install

[CoryADavis]

That out-of-sync scenario has the potential to occur when any package that uses native libraries is updated.

Typically, you would not want to run a set of commands like that in your build pipeline, because once the Podfile.lock is removed, you no longer have a guarantee of what dependencies will be resolved, nor do you have a guarantee that what builds successfully once will build successfully again.

Those are, however, in addition to the --repo-update flag on pod install, the commands a developer would likely use in their local (macOS) environment if any build errors occurred while updating packages.

Ideally, a remote build using a Mac could be triggered on pull request submissions (and updates to those submissions) that change pubspec.lock, which could allow someone with a Mac to help close out a pull request with a failing build before it's merged, or allow the Windows developer to experiment by updating the pull request, and later squash their experiments.

[M123-dev]

Thats a good idea @CoryADavis and should not be hard to implement, what should be the commands which should run in the workflows

on every pr:

• cd ios
• rm -rf Pods
• rm Podfile.lock
• flutter pub get
• pod install

(for a clean re-generation)

for builds:

• pod install (or is this all taken care of by pub get and flutter build)

Or am I missing something

[monsieurtanuki]

once the Podfile.lock is removed, you no longer have a guarantee of what dependencies will be resolved

@CoryADavis Maybe maybe not, as in pubspec.yaml we use exact version numbers (e.g. image_picker: 0.8.7), and not best version number (e.g. image_picker: ^0.8.7). Therefore I would expect some determinist behavior there, and a Podfile.lock re-created from scratch would always match perfectly our exact version numbers. Wouldn't it?

[CoryADavis]

once the Podfile.lock is removed, you no longer have a guarantee of what dependencies will be resolved

@CoryADavis Maybe maybe not, as in pubspec.yaml we use exact version numbers (e.g. image_picker: 0.8.7), and not best version number (e.g. image_picker: ^0.8.7). Therefore I would expect some determinist behavior there, and a Podfile.lock re-created from scratch would always match perfectly our exact version numbers. Wouldn't it?

I think you're correct, with fully pinned dependencies in the pubspec.yaml, the Podfile.lock should be deterministically generated. I think the only exception would be if it cannot be generated at all, due to a repo being outdated. But, being outdated shouldn't happen in server builds (without some sort of intentional caching).

[CoryADavis]

Thats a good idea @CoryADavis and should not be hard to implement, what should be the commands which should run in the workflows

on every pr:

• cd ios
• rm -rf Pods
• rm Podfile.lock
• flutter pub get
• pod install

(for a clean re-generation)

for builds:

• pod install (or is this all taken care of by pub get and flutter build)

Or am I missing something

For the build, it should all be taken care of by the flutter build command, yep!