Ability to detect pub run environment

[DartBot]

This issue was originally filed by @seaneagan

---

AFAICT pub run will break unscripted's tab-completion feature:

    https://github.com/seaneagan/unscripted#tab-completion

For a script named 'foo.dart' the completion script it installs will reference foo.dart or foo depending on configuration. But to work with pub run it would need to reference pub run foo during development, and foo during production. So to support that I would need to be able to detect if the script is being run via pub run. I think a nice way to support that would be a -D parameter, for example pub run could call one of the following:

    dart -Dpub.run=true foo.dart
    dart -Dpub.command=run foo.dart
    dart -Dpub.dev=true foo.dart

(the latter 2 would allow supporting pub serve as well)

I suppose I could add a hidden argument to all unscripted scripts and instruct my users to add it when using pub run:

    pub run foo --pub-run [other args]

but that is error prone and redundant.

[kasperl]

Added Area-Pub, Triaged labels.

[nex3]

We're going to start spawning an isolate for the internal process, so we can't pass special arguments to dart.exe for it.

Can you provide more detail on how your tab completion works and how you'd like it to work with pub run?

---

Removed Type-Defect label.
Added Type-Enhancement label.

[DartBot]

This comment was originally written by @seaneagan

---

Say you have foo.dart implemented with unscripted with TAB-completion enabled. Then you can do:

    foo.dart --completion install

which will install a completion script to ~/.bashrc (or ~/.zshrc if $SHELL is 'zsh'). That completion script needs to call back into foo.dart to get the dynamic completions. It currently does so by calling foo.dart --completion. I guess there are actually a couple issues when trying to do this with pub run:

1. typing pub run foo won't trigger completions for foo.dart, but rather for pub
2. (this issue) the completion script output by pub run foo --completion install would need to reference pub run foo --completion.

I guess the only options to solve 1) would be creating a wrapper foo script which calls pub run foo, or settle for testing TAB-completion only after the command has been added to the PATH via whatever interface is added for issue #18539.

It would still be nice to be able to detect that the script is being run via issue #18539 (which removes the .dart suffix), that way unscripted can know to refer to foo instead of foo.dart in the completion script, and in help text. Presumably that would be possible as the shell script added to the path should call the dart vm directly, so could be pass -D options, or set regular environment variables.

[nex3]

Does Platform.executable not give you the information you need?

[DartBot]

This comment was originally written by @seaneagan

---

I assume the same dart executable would be used by pub run as the one
that's on the system PATH. Assuming they are both coming from the same
SDK's bin dir. So I don't think so.

[nex3]

Sorry, I meant Platform.script, not Platform.executable.

In general, we're planning on moving towards a world in which all pub-based executables are run via "pub run", at least under the covers. If I understand you correctly, though, the main thing you need is the ability to figure out what command-line invocation will reliably re-run the current script. Is that right?

[DartBot]

This comment was originally written by @seaneagan

---

Correct. I do use Platform.script already, the main thing I have to determine is whether to include the '.dart' part. Ideally, deployed scripts should not be invoked with '.dart', to abstract their implementation, but I wonder if there are some scenarios for keeping it like if you need to pass custom flags to the dart vm, but maybe pub run will allow that somehow?

I guess once issue #18539 is fixed, and supports installing scripts from path packages, then it should be pretty easy to invoke scripts without '.dart' even during development, something like:

    pub get -g -s=path /path/to/foo:foo

So maybe just requiring all scripts to be invoked without '.dart' is not so bad, but it would still be nice to not make that restriction (or require an explicit configuration) if I don't have to.

I didn't realize executables added to the PATH (issue #18539) would be run via pub run underneath, thought that that was going to be the equivalent of pub build where it pre-builds everything.

[nex3]

In the future we're planning for, all instances of invoking a command-line Dart script will follow one of two conventions: either running "script [args]" directly (which will "pub run" the global version under the covers) or running a local executable using "pub run" explicitly. As I understand it, the latter can't easily support tab completion without cooperation from pub, which is a bigger issue, so the former is the primary concern. This means that you can pretty reliably assume that the executable shouldn't be invoked with ".dart", so I don't think you'll end up needing this functionality for what you're trying to do.

[DartBot]

This comment was originally written by @seaneagan

---

Yep, and I'd like my users to be able to avoid explicitly running pub run
at all by instead installing their in-development scripts (from "path"
packages, not "hosted") to their PATH. Then I can assume "script [args]"
in all cases, and my users will be able to test their TAB-completion during
development. I'll add a comment to issue #18539 to request it to support
"path" dependencies, and then file a separate issue if issue #18539 is
marked fixed without that feature.

You can go ahead and close this one out. Thanks!

[nex3]

Added NotPlanned label.

[DartBot]

This issue has been moved to dart-lang/pub#1020.