pub doesn't support --enable-experiment=non-nullable

[mit-mit]

bin mit$ ./pub run --enable-experiment=non-nullable ~/tmp/app01/bin/main.dart
Could not find an option named "enable-experiment".

[a-siva]

Moved this issue to the pub repo at dart-lang/pub#2436

[kevmoo]

The way to implement this will be in the SDK wrapper scripts – not in the pub repo.

[mit-mit]

Copying over comment from @natebosch in #41403:

The idea here is that we'd support a minimal amount of arg parsing in the script so that pub --enable-experiment=non-nullable run gets turned into VM argument correctly.

[mit-mit]

@kevmoo @natebosch do we have any existing scripts that do something like this?

[natebosch]

do we have any existing scripts that do something like this?

Not that I'm aware of. It would likely involve some manual argument iteration and string prefix comparison for --enable-experiment=. I might be able to help with the bash script, It would take me longer to figure it out in the windows one.

[jonasfj]

In bash we can do this with:

if [[ "$1" == '--enable-experiment='* ]]; then
  VM_OPTIONS+=("$1")
  shift;
fi

But for .bat files I can't find a good solution this question on stackoverflow links two similar questions, all 3 have multiple solutions, but none of them can handle arguments with quotes, spaces and equal signs... All things that could likely occur in arguments passed through pub run.

note. VM options can already be passed with:
DART_VM_OPTIONS='--enable-experiment=non-nullable' pub run ...

[jonasfj]

@sigurdm, is there any reason we use isolates for pub run if we were to use sub-processes we could handle the --enable-experiment flag in pub, and it would be easier to embed pub in dartdev.

Also, I can't help but wonder if --enable-experiment won't cause problems with our snapshotting, if you were to switch it on/off, just thinking someone might do so with pub run test.

[natebosch]

none of them can handle arguments with quotes, spaces and equal signs

The VM only handles the argument passed with an equals sign. We don't have to worry about any strangeness around spaces, which means we can also probably avoid any concerns about quoting.

[natebosch]

I can't help but wonder if --enable-experiment won't cause problems with our snapshotting, if you were to switch it on/off, just thinking someone might do so with pub run test.

That's a good point, I don't know how snapshots will work with this.

[jonasfj]

We don't have to worry about any strangeness around spaces, which means we can also probably avoid any concerns about quoting.

I got the impression that the .bat solutions would be buggy if any of the arguments had such things. To be fair though, I don't know that our current solution can handle these corner cases.
Since it's probably rather rare that windows users pass complicated arguments through pub.

In any case, the snapshot concerns gives me reason to pause, and think if perhaps it's better if pub run creates a subprocess instead of an isolate.

[sigurdm]

@sigurdm, is there any reason we use isolates for pub run if we were to use sub-processes we could handle the --enable-experiment flag in pub, and it would be easier to embed pub in dartdev.

I don't know of the reason.
My guess would be that an isolate starts slightly faster, and consumes less memory because it can share the VM. Not sure how significant that is though.

Also, I can't help but wonder if --enable-experiment won't cause problems with our snapshotting, if you were to switch it on/off, just thinking someone might do so with pub run test.

One option would be to completely drop precompilation (and ignore existing snapshots) if --enable-experiment. That would make pub run slower with the experiment, but ensure consistency.

Otherwise we would have to save information about the configuration when the snapshot was created, so we can recreate it the configuration changed. That might be handy for other configuration than just --enable-experiment.

[natebosch]

My guess would be that an isolate starts slightly faster, and consumes less memory because it can share the VM. Not sure how significant that is though.

I think it used to be fairly significant. I haven't measured in a while.

One option would be to completely drop precompilation (and ignore existing snapshots) if --enable-experiment. That would make pub run slower with the experiment, but ensure consistency.

This seems like a good idea. I think we'd need a way to ask within the runtime whether any experiments are enabled.

[franklinyow]

@jonasfj This issue is in the critical path of tech preview. I like to get a ETA on this so I can build a timeline. Thanks!

[jonasfj]

Hmm, looking at the dartdev run it uses a subprocess. Hence, that must be good enough for pub run too.

Running pub with experiments is undesirable anyways. As it might break/affect pub which is not what you want when you do pub run --enable-experiment=...

@franklinyow, hmm, we have a few things to refactor to get this going. But a week or maybe two (given all the holidays coming up).

[franklinyow]

Any update on this?

[mit-mit]

@sigurdm @jonasfj is dart-lang/pub#2493 still the active PR for this?

[sigurdm]

Yes

[rakudrama]

How can we enable the experiment on travis?
AFAIK the travis task delegates to pub run test.
I want to be sure package:fixnum is tested both opt-in and opt-out.

This is an example on travis where I tried adding --enable-experiment=non-nullable to a travis test.
dart-archive/fixnum@3d2eb5b
It fails like this:
https://travis-ci.org/github/dart-lang/fixnum/jobs/694414777

/cc @kevmoo

[kevmoo]

Fixed in 64b761b