[flutter_tools] pubspec.yaml environment.flutter constraint not respected by pub get

[neiljaywarner]

steps to reproduce

1. use current stable version flutter 2.8.1
2. in pubspec.yaml use flutter: ">=2.8.0 <2.8.1" or "2.8.0"

Expected behaviour - flutter pub get error

The current Flutter SDK version is 2.8.1.

Because app_name requires Flutter SDK version <2.8.1, version solving failed.

Actual behaviour: pub get succeeds; vesrion constraint fails, overzealous dev or build server just ugpraded to a newer version of flutter without discussion or any testing at all or possibly even an easy OOTB way to see what version was built with

[darshankawar]

@neiljaywarner
Is there any reason why you need to change it to >=2.8.0 <2.8.1" or "2.8.0" ?
On latest stable 2.8.1, the dart version supported is 2.15.1 (from flutter doctor) .

[github-actions]

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
If you find this problem please file a new issue with the same description, what happens, logs and the output of 'flutter doctor -v'. All system setups can be slightly different so it's always better to open new issues and reference the related ones.
Thanks for your contribution.

[neiljaywarner]

@darshankawar sorry I didn't see your question.
I want to pin it so if I go away for 6 to 18 months and come back I know what flutter version this project expects and will compile on.
Yes I know updating is important but so is keeping everyone on a project on the same tested version

[neiljaywarner]

Specifically I would like it to behave as expected consistently in both directions and enforce upper constraint as well as lower constraint. Not just force/remind devs to upgrade when the team decides to but disallow them to race ahead. For example ci should not be able to make a build with a flutter version never tested by qa ....sent from my phone

…

On Mon, Jan 10, 2022, 8:58 AM github-actions[bot] ***@***.***> wrote: Reopened #95472 <#95472>. — Reply to this email directly, view it on GitHub <#95472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXBGYPMMDPT4S5GKON7BRLUVLXY5ANCNFSM5KJIXPCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[darshankawar]

The current version with upper constraint I have is sdk: ">=2.8.1 <3.0.0" which works well, indicating the min lower and max upper version constraint, so I am not entirely sure what your request here is.

[neiljaywarner]

What you have should disallow 3.0 0 it fails the constraint of bring less than or equal to 3.0 In fact 3.0 would pass and be compile and build except for the fact that 3.0 is a major version and would have breaking changes. Honestly I want to be able to constrain to 2.8.1 for example so 2.8.0 fails and 2.8.2 fails. I don't ever want the project upgraded silently by random dev or random server with no pr review or discussion. This concept weeks with the lower constraint but upper constraint is broken and as far as I could tell does nothing. Thanks ....sent from my phone

…

On Tue, Jan 11, 2022, 12:00 AM darshankawar ***@***.***> wrote: The current version with upper constraint I have is sdk: ">=2.8.1 <3.0.0" which works well, indicating the min lower and max upper version constraint, so I am not entirely sure what your request here is. — Reply to this email directly, view it on GitHub <#95472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXBGYND6UZTHEZFVZSECILUVPBPTANCNFSM5KJIXPCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[darshankawar]

Keeping it open and labeling for further input.

[neiljaywarner]

@darshankawar is it clear my goal now? I want to pin a specific version so neither ci/cd nor a new dev "accidentally" upgrades the flutter version for any builds they distribute to anybody and it won't compile at all on an incorrect flutter version. + @goderbauer
but instead that every single upgrade to flutter version no matter how small passes code review and qa and then every single developer has to use the specified flutter version when building the project.

[maheshmnj]

I am quite not sure if this is currently supported. I ran flutter pub get on stable 2.10.4 by specying the SDK versions as below in the pubspec.yaml

dependencies:
  flutter:
    sdk:  ">=2.5.1 <2.8.1"

and pub get fails with

Because test_app depends on flutter from SDK which doesn't exist (unknown SDK ">=2.5.1 <2.8.1"), version solving failed.

and using the below constraints still fails, so it makes me wonder if its a bug or is it not supported

dependencies:
  flutter:
    sdk:  ">=2.10.2 <2.13.0"

Because test_app depends on flutter from sdk which doesn't exist (unknown SDK ">=2.10.2 <2.13.0"), version solving failed.
pub get failed (server unavailable) -- attempting retry 9 in 64 seconds...

cc: @christopherfujino

[christopherfujino]

Per https://dart.dev/tools/pub/pubspec#sdk-constraints, the way to do this is via the environment key, like:

environment:
  # This is the dart constraint
  sdk: '>=2.10.0 <3.0.0'
  # This is the Flutter SDK
  flutter: 2.8.0

From the link:

A Flutter SDK constraint is satisfied only if pub is running in the context of the flutter executable, and the Flutter SDK’s version file matches the given version constraint. Otherwise, the package will not be selected.

However, this doesn't seem to be enforced when I locally try this.

I believe this function call should be validating this: https://github.com/dart-lang/pub/blob/master/lib/src/validator/sdk_constraint.dart#L81

[neiljaywarner]

@christopherfujino @darshankawar @maheshmnj yes, that's the whole point, it is supposed to work but doesn't.

[christopherfujino]

@christopherfujino @darshankawar @maheshmnj yes, that's the whole point, it is supposed to work but doesn't.

@neiljaywarner you don't need to get snippy with me, I'm just documenting more context, to help solve this.

[neiljaywarner]

I am so sorry. I did not mean to be snippy I was just concerned about clarity and I think we are in agreement. I love flutter and dart and I appreciate the response and I'm very sorry please forgive me . ....sent from my phone (I appreciate you providing the context)

…

On Mon, Apr 11, 2022, 11:43 AM Christopher Fujino ***@***.***> wrote: @christopherfujino <https://github.com/christopherfujino> @darshankawar <https://github.com/darshankawar> @maheshmnj <https://github.com/maheshmnj> yes, that's the whole point, it is supposed to work but doesn't. @neiljaywarner <https://github.com/neiljaywarner> you don't need to get snippy with me, I'm just documenting more context, to help solve this. — Reply to this email directly, view it on GitHub <#95472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXBGYIBNR6N6T5LJQN7BG3VERJEPANCNFSM5KJIXPCQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[christopherfujino]

Another filing of this in #80610

[christopherfujino]

Ok, in playing around with this further, it seems that lower bounds are respected (e.g. flutter: '>=5.0.0' does throw an error) but upper-bounds are not (e.g. flutter: '<2.2.0' does not throw an error). Also, exact pins are ignored (e.g. flutter: '2.3.4' does not throw).

I believe there is a historical reason for this. Also, I imagine it would be difficult to enable upper bounds, as this would be a breaking change. However, it seems exact pins would be very useful, and would be relatively safe to enable.

@Hixie @mit-mit do you remember the context around this?

[mit-mit]

Yeah, I remember. We changed this to enable the roll-out of Flutter 2; prior to that we had both a lower and upper bound, but when we went to Flutter 2 -- which wasn't a major breaking release from a semver perspective -- we would have "broken the world", so we removed the upper-constraint.

Pinning to a single SDK is a request I've heard fairly often. It can be useful for teams that want to ensure all team members are on the same SDK. Unfortunately a constraint like flutter: x.y.z means use x.y.z as the lower and upper constraint, and sine the upper constraint is ignored in Flutter it's only a lower constraint.

[christopherfujino]

Yeah, I remember. We changed this to enable the roll-out of Flutter 2; prior to that we had both a lower and upper bound, but when we went to Flutter 2 -- which wasn't a major breaking release from a semver perspective -- we would have "broken the world", so we removed the upper-constraint.

Pinning to a single SDK is a request I've heard fairly often. It can be useful for teams that want to ensure all team members are on the same SDK. Unfortunately a constraint like flutter: x.y.z means use x.y.z as the lower and upper constraint, and sine the upper constraint is ignored in Flutter it's only a lower constraint.

Is the blocker to enabling flutter: x.y.z to exactly constrain the version a technical or policy one?

[neiljaywarner]

i also notice
flutter: "2.10.5" # pubspec.yaml

becomes
flutter: ">=2.10.5" # pubspec.lock

[simplifit-michael]

It is also a technical issue.
in my company we work on several project with several flutter versions.

eg:
one project is using flutter 3.3.2
the newest one is using flutter 3.7.0

=> the flutter_localizations of flutter 3.7.0 had breaking changes adding parameters. so when I want to use a string from the localisation it changed from being S.of(context)!.stringwithparameter.replaceAll('${parameter}',value) to S.of(context)!.stringwithparameter(value)
Also other dependencies have breaking changes if the flutter version is newer then the project defines.

Therefore a dev should be infomed when he uses a flutter version which is "too new"

hope that helps :)

[AlexV525]

Using a fixed Flutter version would be enough for cases that force CI/CD not to accidentally upgrade to a newer version of Flutter (mostly happened during a new stable version released but the project has not been migrated). However, enabling version constraints like 3.10.x might be a little bit more helpful in a real-world project.

[vasilich6107]

Hi.
it would be nice to resolve this issue and make the version notation similar to how we work with them in other deps in pubspec.

The main issue is that it is not obvious if I specify flutter 3.3.2 that some magic code decides that it means >=3.3.2

[guneyozsan]

We migrated to flutter recently and flutter version installed among team was one of the first team issues we hit. Setting up a new machine, or coordinating version upgrades among team would be difficult. I can also foresee debugging weirdness in CI if it silently gets a breaking version of flutter.

In our case, we don't essentially need a range but locking to a wildcard version could be nice (e.g. 3.19.x or 3.x.x).

Also, the range silently failing is hard to notice unless you notice the difference in the diff:

pubspec.yaml:
flutter: '>=3.19.0 <4.0.0'
pubspec.lock:
flutter: ">=3.19.0"