Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to detect pub run environment #19580

Closed
DartBot opened this issue Jun 20, 2014 · 11 comments
Closed

Ability to detect pub run environment #19580

DartBot opened this issue Jun 20, 2014 · 11 comments
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Jun 20, 2014

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
Copy link

kasperl commented Jun 23, 2014

Added Area-Pub, Triaged labels.

@nex3
Copy link
Member

nex3 commented Jun 23, 2014

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
Copy link
Author

DartBot commented Jun 30, 2014

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
Copy link
Member

nex3 commented Jun 30, 2014

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

@DartBot
Copy link
Author

DartBot commented Jun 30, 2014

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
Copy link
Member

nex3 commented Jun 30, 2014

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
Copy link
Author

DartBot commented Jul 1, 2014

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
Copy link
Member

nex3 commented Jul 1, 2014

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
Copy link
Author

DartBot commented Jul 1, 2014

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
Copy link
Member

nex3 commented Jul 1, 2014

Added NotPlanned label.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

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

@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed priority-unassigned labels Mar 1, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

4 participants