Pub-dev: Block upload of packages depending on -dev Dart SDKs – unless they are prerelease

[kevmoo]

We want to limit upload of packages that depend on unreleased features.

This logic should exist (ideally) in both the pub client and pub-dev

bool allowPublish(VersionConstraint sdkConstraint, Version packageVersion) {
  if (sdkConstraint.isEmpty || sdkConstraint.isAny) {
    // I hope we already do this!
    return false;
  }

 final sdkConstraintRange = sdkConstraint as VersionRange;

  final sdkLowerBound = sdkConstraintRange.min;
  if (sdkLowerBound == null) {
    // I hope we block this, too!
    return false;
  }

  if (sdkLowerBound.major < 2) {
    // Don't worry about SDK constraints before v2
    return true;
  } else if (sdkLowerBound.major == 2 && sdkLowerBound.minor < 8) {
    // Don't worry about SDK constraints before v2.8
    return true;
  }

  // If it's not a prerelease, don't worry about it!
  if (!sdkLowerBound.isPreRelease) {
    return true;
  }

  if (packageVersion.isPreRelease) {
    // If the package is prerelease, allow publish!
    return true;
  }

  // package is NOT pre-release
  // SDK constraint lower bound
  //   major.minor >= 2.8
  //   IS prerelease
  // NOT ALLOWED!
  return false;
}

[kevmoo]

CC @mit-mit @munificent @jonasfj – sometimes writing out the code is easier than a paragraph of text.

I hope I captured the thought process here

Also CC @natebosch @jakemac53 – care about packages

[jonasfj]

We were discussing this a bit yesterday.. In my mind the problem is that this doesn't enforce the transitive property.
Example: I can still publish package:foo version 1.0.0 which depends on package:bar version 1.0.0-dev, even if package:bar requires Dart SDK version 2.8.0-dev.

Option (A), we could simply require that the transitive dependencies of a non-pre-release package may not have SDK constraints requiring a pre-release of the Dart SDK.
Example: I can publish package:foo version 1.0.0 which depends on package:bar version 1.0.0-dev, only if package:bar doesn't require a pre-release of the Dart SDK.

This has following downsides:

1. This doesn't enforce the transitive property going forward. Because a future pre-release of package:bar, say, version 1.0.0-dev2 is allowed to depend on a pre-release of the Dart SDK.
2. It's seems arbitrary to distinguish between allowing dependency on package pre-releases in non-pre-release package versions, but not allowing dependency on SDK pre-releases in non-pre-release package versions.
3. It similarly, seems arbitrary to distinguish between Flutter pre-releases and Dart pre-releases when determining if a package can be published with a non-pre-release version number.

Option (B), one could argue that depending on a pre-release of any pub package or Dart/Flutter SDK should be forbidden in non-pre-release versions. That would enforce the transitive property.
Example: package:foo version 1.0.0 cannot depend on package:bar version 1.0.0-dev (regardless of what package:bar depends on).
This has the downside (or upside) of making pre-release versions infectious, this will undoubtedly cause churn / toil in the community. It's also a rather strong opinion to be taking.

Option (C), one could argue that ascribing semantics to pre-releases is unwanted, and if a stable release of package:foo wants to depend on an pre-release of another package then we have to assume the author knows what they are doing. In this scenario a warning before publishing a package which depends on a pre-release of any kind would be warranted.
Example: when publishing package:foo version 1.0.0 the author should get a warning, if package:foo has dependency on a pre-release of either another package, Dart or Flutter.

---

I think (C) is an uncontroversial option. That said (B) is also attractive, given that we already ascribe different semantics to pre-releases, by:

• Displaying pre-releases differently on pub.dev, and,
• Omitting pre-releases in the less-than operator in pub_semver (ie. <3.0.0 does not allow 3.0.0-dev, even if 3.0.0-dev < 3.0.0).

[mit-mit]

I think c) might be enough, at least initially

[jakemac53]

I am curious how common it is today for a package to be violating option b? That is the most desirable option in terms of correctness imo. It is a pretty strong stance to take though.

Option c would still be an improvement but unfortunately we have seen in the past that people will just ignore warnings.

We could also consider making the way warnings work be a bit more difficult to bypass. For instance if you had to actually re-run the publish command with a scary flag - which you could only discover by actually reading the pub output.

[kevmoo]

I like the idea of requiring a --force – although then folks get used to
just running pub with --force

We could also require confirmation via keyboard either way...

On Wed, Feb 26, 2020 at 8:18 AM Jacob MacDonald [e-mail]
wrote:

I am curious how common it is today for a package to be violating option
b? That is the most desirable option in terms of correctness imo. It is a
pretty strong stance to take though.

Option c would still be an improvement but unfortunately we have seen in
the past that people will just ignore warnings.

We could also consider making the way warnings work be a bit more
difficult to bypass. For instance if you had to actually re-run the publish
command with a scary flag - which you could only discover by actually
reading the pub output.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/pub-dev/issues/3375?email_source=notifications&email_token=AAAEFCU7BVPT2MZGXAVIZ2LRE2I4HA5CNFSM4K3WQF62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENA4BTY#issuecomment-591511759,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEFCSPVT45F4WN3IHOLMDRE2I4HANCNFSM4K3WQF6Q
.

[jonasfj]

@jakemac53,

I did some analysis (quick so it's possible there is bugs):

If we consider all versions:

• 1798 package versions has pre-release deps and is NOT a pre-release
• 15721 package versions has pre-release SDK dep and is NOT a pre-release.

If only consider latest version the numbers are:

• 193 package versions has pre-release deps and is NOT a pre-release
• 1828 package versions has pre-release SDK dep and is NOT a pre-release.

[natebosch]

although then folks get used to just running pub with --force

😈

Your package has 3 warnings with a hash of 1fa4af2.
To publish anyway rerun with --allow-warnings=1fa4af2

Folks who want to keep pushing with a set of known warnings could do so, but it would not be easy to do accidentally across different packages or for new warnings etc.

[jonasfj]

To publish anyway rerun with --allow-warnings=1fa4af2

hehe, I like the idea it -- but making warnings harder to ignore is perhaps orthogonal.

---

On topic, @kevmoo, are you happy with option (C), a warning?
(then we should land https://github.com/dart-lang/pub/pull/2356)

[jonasfj]

Also, how do people think about warning about dependency on a pre-release of package from a non-pre-release version.

Specifically, do we only want to warn for SDK constraints, following logic in (B) we should make it transitive.

[kevmoo]

Yes, (C) is great!

[natebosch]

I'd be happy with starting as a warning and either escalating to error after some time, or making warning harder to ignore.

[kevmoo]

I'd be happy with starting as a warning and either escalating to error after some time, or making warning harder to ignore.

I agree in principal, but just a few packages "leaking" into the pub site can cause us a lot of problems.

[jonasfj]

but just a few packages "leaking" into the pub site can cause us a lot of problems.

Really? I mean packages that depend on a pre-release SDK like 2.10-dev will get low score AND cannot be installed from a 2.7 SDK. It's only a problem when a stable 2.10 SDK is released.
And it's only a problem if the semantics between 2.10-dev and 2.10 changed so much that the package in question is affected. And the package in question haven't been published in a newer version that works with 2.10.

That said, it seems nice to encourage packages depending on pre-releases to also be pre-releases.