Consider recording the exact sdk version in pubspec.lock

[sigurdm]

Currently the pubspec.lock locks down the dependent packages with a content hash (at least for hosted and git packages).

But for the sdk (be it flutter or dart) it records the range of sdks for which the lockfile is valid - the intersection of all the sdk constraints of all dependencies.

This is (as far as I can tell) mainly an optimization, so we don't redo the resolution after upgrading the sdk unless we fall outside the sdk constraint of some package.

Recording the exact sdk version number would help towards the hermeticity of the build.

With pub get we could update the lockfile, and notify the user that the sdk has changed (as we currently do when a package is changed by pub get).

Something along the lines of

> dart pub get # dart 3.8.0
+ Dart SDK 3.8.0

> dart pub get # dart 3.9.0
Resolving dependencies... 
> Dart SDK 3.9.0

With pub get --enforce-lock-file we could fail if the sdk version in production was different from the dev environment.

cc @jakemac53 @jonasfj @szakarias @dcharkes @munificent

WDYT

[dcharkes]

This came up in the discussions on dart install where we rely on storing a pubspec.lock with an installed application bundle to know the versions. The pubspec.lock doesn't store the specific Dart SDK version making the pubspec.lock having only partial information about versions used. (Storing the used SDK version separately next to the pubspec.lock seems weird when pub is in charge of version information.)

[jakemac53]

For package:build we just tracked this separately in our own file, and I think that is fine.

I think for the use case that the pubspec.lock is actually intended for, it is doing the correct thing. I wouldn't optimize it to fit the requirements of some other tool, when that makes the core use case less efficient. Those tools can always track the exact SDK version separately if its something that matters to them.