Pub: Error in pub when packages don't have a lower-bound SDK constraint

Created on 2 Nov 2020  路  31Comments  路  Source: dart-lang/pub

Outdated proposal one; for the current proposal see https://github.com/dart-lang/pub/issues/2707#issuecomment-720599514.


When pubspec.yaml does not contain a lower-bound SDK constraint (or doesn't contain an SDK constraint). We should:

  • [ ] (A) infer a _default language version_ of 2.0, which should be written to .dart_tool/package_config.json, and,
  • [ ] (B) show a warning in dart pub get, advicing the user to specify an SDK constraint.
        Warning: `pubspec.yaml` has no SDK constraint lower bound; defaulting to language version 2.0.
        You should edit pubspec.yaml to add an SDK constraint, e.g.:
        environment:
          sdk: '>=2.0.0 <3.0.0'

Blocked, waiting for feedback.

CRITICAL feature-request

Most helpful comment

I agree that peoples apps are most likely broken when they update to 2.12 if they have no sdk constraint, and thus enforcing the constraint should just help them find and resolve the issue earlier.

Yes, hence, why I argued that we should make pub get fail, if pubspec.yaml does not contain any lower-bound SDK constraint.

All 31 comments

I prefer not to mention the "language version" part, which may be nomenclature some devs are not familiar with:

Warning: pubspec.yaml has no SDK constraint lower bound; defaulting to 2.0.0.
You should edit pubspec.yaml to contain an SDK constraint:

environment:
  sdk: '>= 2.0.0 <3.0.0'

IIRC if there is no SDK constraint, the current tooling assumes Dart 1.x, and we did similarly in pre-checks for pana. Same thing for unspecified lower bound...

Right, but I'm not sure that's very useful anymore?

IIRC if there is no SDK constraint, the current tooling assumes Dart 1.x

We do when consume from pub.dev, but not when reading source on the users machine. If there is no SDK constraint, we just assume the code works with the current Dart SDK that the user has installed.

November 3rd: updated agreed to proposal:

Now:

  • Announce a breaking change that having a Dart SDK constraint in a pubspec is required
  • Add an error to pub get (the dart.dev link in the warning contains docs that explain how to pick a lower constraint with/without null safety)
```
Warning: pubspec.yaml has no SDK constraint lower bound; defaulting to <current SDK version>.
You should edit pubspec.yaml to contain an SDK constraint: http://dart.dev/go/sdk-constraint
```

Alternate proposal:

Now:

  • Announce a breaking change that having a Dart SDK constraint in a pubspec is required
  • Add a warning to pub get (the dart.dev link in the warning contains docs that explain how to pick a lower constraint with/without null safety)
```
Warning: pubspec.yaml has no SDK constraint lower bound; defaulting to <current SDK version>.
You should edit pubspec.yaml to contain an SDK constraint: http://dart.dev/go/sdk-constraint
```

In Dart 3:

  • Make it an error in pub to not have an Dart SDK constraint

While we still don't have consensus on the concrete solution, I believe we have an agreement that something has to happen here. Tagging as a beta experience blocker.

@jakemac53 @natebosch any reactions to the alternate proposal ?

Yes, with the caveat of if we make this an error in Dart 3 it needs be something we ensure we can do in a way that doesn't break users on older sdks.

If it's a client side error, then given pub ships in the SDK, how could it break older SDKs?

If it's a client side error, then given pub ships in the SDK, how could it break older SDKs?

The clients might be asking for packages that violate this rule, and the server might start failing to parse/serialize the pubspec or something like that. It depends how it is implemented.

I agree if this is client side _only_ (part of the get/upgrade/run etc commands only) then it should be safe to do.

A warning on pub get/pub upgrade SGTM. Making it an error in Dart 3.0 also SGTM.

I believe SDK constraints is already a requirement for publishing.

Now we have yaml-editing capabilities, we could even make a way to automatically insert an sdk-constraint if it is missing...

Yes, I was pondering if something like dart pub fix could add it?

@natebosch @jakemac53, in discussing this with @jonasfj, he brought up the point that given this is all client side, and only starting with the pub client in 2.12, we may be giving the developer a better experience by making this an error rather than warning.

The reason is the resolution is likely to fail anyway given their existing deps are not likely to support null safety? Having it be an error means it's fail with a short message saying the SDK constraint is missing. Having it be a warning means they get the SDK constraint warning, and then a bunch of unexpected output about various dependencies not supporting null safety. WDYT?

I am in favor of making the change to require an SDK constraint now. What are we going to suggest as a constraint though?

We probably need a separate page we can link to describing the new meaning attached to the constraint.

We probably need a separate page we can link to describing the new meaning attached to the constraint.

Yeah, we need to explain language versioning.

We have: https://dart.dev/guides/language/evolution#language-versioning

We could add a sub-section for null safety, incl, making it clear that selecting the 2.12 language is "soft breaking"

The reason is the resolution is likely to fail anyway given their existing deps are not likely to support null safety?

I don't understand this. If a pub get works in dart 2.10 for a package which hasn't considered null safety at all, I think it's very likely to work in 2.12 still. If we make it an error then it means a pub get which worked in 2.10 would suddenly start failing in 2.12. I think that could be OK if it's trivial to correct the problem, and I think it should be trivial to fix the problem.

I think it's very likely to work in 2.12 still.

My understanding is that it's likely to fail due to https://github.com/dart-lang/pub/issues/2541

.... I have never heard of this error and I did not think it was the plan to do this, cc @leafpetersen

My understanding is that it's likely to fail due to #2541

That looks like it should be a warning, not a failure. Am I misreading?

Sorry, my bad (I have to many different bugs in my head right now). It's a warning indeed!

@jonasfj did you have any reasons to believe it would likely fail?

This warning is likely going to trigger for most projects for an extended period of time, fwiw, even though they _can_ run with null safety (the test package has runner deps that are not migrated such as analyzer).

Given that the check can't actually accurately predict if your app is null safe I think we should remove the warning.

I don't understand this. If a pub get works in dart 2.10 for a package which hasn't considered null safety at all, I think it's very likely to work in 2.12 still.

If you have a pubspec.yaml in your application without a lower-bound SDK constraint. Then:

  • pub get will create a .dart_tool/package_config.json without a languageVersion for the _root package_.
  • dart bin/my_app.dart will identify bin/my_app.dart as belonging to the _root package_.
  • Seeing that there is no languageVersion in for the _root package_ in .dart_tool/package_config.json, dart will run bin/my_app.dart with the _language version_ inferred from the current SDK version.

Hence, any project users have on their machines or on github which doesn't have an SDK constraint will break; when the user upgrades their Dart SDK 2.12.0.

Our templates for example/ in flutter plugins (and packages) has omitted the SDK constraint, see example/pubspec.yaml for package url_launcher version 5.7.8. As I understand it this example app is unlikely to work with language version 2.12.

Yes I agree that peoples apps are most likely broken when they update to 2.12 if they have no sdk constraint, and thus enforcing the constraint should just help them find and resolve the issue earlier.

I agree that peoples apps are most likely broken when they update to 2.12 if they have no sdk constraint, and thus enforcing the constraint should just help them find and resolve the issue earlier.

Yes, hence, why I argued that we should make pub get fail, if pubspec.yaml does not contain any lower-bound SDK constraint.

Yes, hence, why I argued that we should make pub get fail, if pubspec.yaml does not contain any lower-bound SDK constraint.

Thanks, that makes sense to me, a failure sounds like the right approach.

Thanks all, and sorry for the confusion. I've updated https://github.com/dart-lang/pub/issues/2707#issuecomment-720599514

While I slightly agreed that it will probably avoid more trouble to make this an error it is a high price:

Just for having the obvious downside mentioned (besides introducing a breaking change): now it is no longer trivial to make a pubspec.yaml by hand.

It takes quite an effort to write:

environment:
  sdk: '>=2.12.0 <=3.0.0'
  • who knows how to spell "environment" anyways
  • who cares for the non-^ syntax that is required for backwards compat with dart 1.
  • who remembers why you need a lower bound
  • why is the dart sdk constraint called "sdk" not "dart"?
  • you just want to try this great language!).

Almost worse than having to type

class A {
  public static void main(String[] args) {}
}

in java just to write a minimal program.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nex3 picture nex3  路  21Comments

wh120 picture wh120  路  24Comments

jayoung-lee picture jayoung-lee  路  38Comments

crajygemer picture crajygemer  路  24Comments

kevmoo picture kevmoo  路  53Comments