Open gnprice opened 1 year ago
One possible diagnostic factor is that we use Flutter from the main/master channel. Perhaps these updates reflect changes in Flutter's own dependencies?
OK, I now consider this diagnosis confirmed.
At https://api.flutter.dev/ , there's a list of "supporting libraries that ship with Flutter". That list includes almost all of the packages that we've seen updated in this way:
async
collection
material_color_utilities
meta
source_span
test_api
(where collection
is one I see an update for right now, which I'll push soon.)
The two exceptions — the two packages we've seen updated this way that aren't on that list of "supporting libraries" — are test
and test_core
. But: those packages are unusual in having an exact dependency on test_api
. The point of test_api
is precisely to force test
and a few closely-related packages to be upgraded in lockstep. So those exceptions are equally well explained by changes in Flutter's dependencies.
I think for our own purposes the solution is therefore:
The other remaining action item is to see if there's an existing ticket for the upstream issue here:
In that case, the upstream issue is just that when a mere
dart pub get
causes dependencies inpubspec.lock
to change, there should be some message explaining why.
and if not, then file one. Hopefully the behavior here can be less confusing and more transparent for future users of Flutter main.
If I run
flutter pub get
right now, it bumps the version of several of our dependencies:Namely
test
,test_api
,test_core
. It edits thepubspec.lock
file to reflect these changes.We've had this happen several times before: 2b3e7819cac210a67bc96873e95e04cf0535dffb, 0b89ce98823f26128aa05e22376855460049c726, 265143dc8548f19b654a2ea2f8e2521c2ae9e7bc.
This doesn't fit with what I would think the meaning of
pubspec.lock
is, and the meaning offlutter pub get
: I expect the former to serve as a lockfile, and the latter to be the command that respects the lockfile and just installs the exact same versions of our dependencies as the lockfile specifies. There's a different command,flutter pub upgrade
, for when one wants to update what's in the lockfile.And in keeping with my expectations,
flutter pub get
leaves most of the dependencies in place, as the output above shows. By contrast if I runflutter pub upgrade
, it upgrades 15 dependencies instead of 3 (or 12 dependencies, if I do so afterflutter pub get
).(All the same observations apply if I type
dart pub get
anddart pub upgrade
. It seems like theflutter
versions are thin wrappers over thedart
versions; I'm not sure if there's any difference at all.)I'm not sure if this behavior of occasionally upgrading a few dependencies is just a bug in pub, or reflects some subtlety of pub's intended behavior, or somewhere in between. I'm hoping it's a bug that can just get fixed, because it seems pretty inconvenient. Lockfiles were a good invention.
One possible diagnostic factor is that we use Flutter from the main/master channel. Perhaps these updates reflect changes in Flutter's own dependencies? If that is what's driving this, then it adds a further reason for pinning our Flutter SDK version too, i.e. #15.
In that case, the upstream issue is just that when a mere
dart pub get
causes dependencies inpubspec.lock
to change, there should be some message explaining why.