pub commands do not seem to have a way of opting out of null safety when running on a VM that runs in null safe mode by default

[a-siva]

Environment

• Dart version: Dart SDK built including this CL https://dart-review.googlesource.com/c/sdk/+/261140 that flips the VM to run in strong null safety mode by default
• OS kind and version ( Debian 5.18.16-1rodete1 ):
• Are you using the Chinese community mirror or a corporate firewall? No

Problem

pub commands do not seem to have a way of opting out of null safety when running on a VM that runs in null safe mode by default and requires the --no-strong-null-safety flag to be passed explicitly when dealing with packages that are not migrated.

/usr/local/google/home/asiva/workspace/dart-ws2/sdk/out/ReleaseX64/dart-sdk/bin/dart pub global activate webdev

fails as follows:

Building package executables... (2.9s)
Failed to build webdev:webdev:
../../../../../.pub-cache/hosted/pub.dartlang.org/webdev-2.7.11/bin/webdev.dart:5:1: Error: A library can't opt out of null safety by default, when using sound null safety.
// @dart = 2.9
^^^^^^^^^^^^^^

Please see https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8799853107143994081/+/u/test_results/new_test_failures__logs_ for an example of the above failure in a test scenario.

[jonasfj]

@a-siva is this still necessary?

I can't really imagine we'll want anyone to pass this flag to dart pub global activate?

We could, but supporting it would likely involve some hacks, because dart pub global activate generates binstubs and such that need to include the command for launching the snapshot.

I see that package:webdev looks to be fully migrated, at-least I only see a few test cases when searching through the repository for webdev. So is this still relevant?

[mit-mit]

I just tried on my local build of SDK head, and it seems to work:

mit@mit-gbuntu:~/dev/dartsdk/sdk$ ./out/ReleaseX64/dart-sdk/bin/dart pub global activate webdev
+ args 2.3.1
...
Building package executables... (6.2s)
Built webdev:webdev.
Installed executable webdev.
Warning: Pub installs executables into $HOME/.pub-cache/bin, which is not on your path.
You can fix that by adding this to your shell's config file (.bashrc, .bash_profile, etc.):

  export PATH="$PATH":"$HOME/.pub-cache/bin"

Activated webdev 2.7.12.
mit@mit-gbuntu:~/dev/dartsdk/sdk$

[jonasfj]

I chat @sigurdm demonstrated that webdev version 2.7.8 has an issue:

$ ~/.dvm/darts/3.0.0-0.0.dev/bin/dart pub global activate webdev 2.7.8
Package webdev is currently active at version 2.7.12.
+ _fe_analyzer_shared 34.0.0 (51.0.0 available)
< dds 2.2.1 (was 2.5.0) (2.5.0 available)
< dds_service_extensions 1.3.0 (was 1.3.1) (1.3.1 available)
< devtools_shared 2.14.0 (was 2.20.0) (2.20.0 available)
< dwds 12.1.1 (was 16.0.1) (16.0.1 available)
< vm_service 8.3.0 (was 9.4.0) (9.4.0 available)
< webdev 2.7.8 (was 2.7.12) (2.7.12 available)
These packages are no longer being depended on:
- file 6.1.4
Building package executables... (7.4s)
Failed to build webdev:webdev:
../../.pub-cache/hosted/pub.dev/webdev-2.7.8/bin/webdev.dart:5:1: Error: A library can't opt out of null safety by default, when using sound null safety.
// @dart = 2.9
^^^^^^^^^^^^^^

But I think we should accept that, since we control most of the packages with issues like this. And most of them have been migrated already.

More, importantly, dart pub global activate is a niche use-case, and nobody is going to want to do --no-sound-null-safety, then it's probably better to stick with an older Dart SDK.

In any case, @a-siva if you think we need this we'll look into adding it.

[a-siva]

I am not familiar with the lay of the land in terms of packages in the ecosystem that have not been migrated yet and would need to function with Dart 3.0.0.
In our local testing webdev came across as one such packages and it is possible there is a newer version of thiac package available that is migrated and it is possible for all users of this package to upgrade to the newer one.
If you think there is never a case of someone wanting to use an unmigrated package with Dart 3.0 sdk even by internal apps then sure go ahread and close this as 'will not fix'

[sigurdm]

I don't think using unmigrated code will be possible in 3.0.0.

@mit-mit can you confirm?

Closing for now

[mit-mit]

In 3.0.0 stable that will indeed not be possible at all. There was some debate as to whether we might need the support t resolve these temporarily in alpha, but I think we're nearly there and seem to be able to get there without that support.