First stab at "pub run" command.

sdk/lib/_internal/pub/lib/src/command/run.dart

Index: sdk/lib/_internal/pub/lib/src/command/run.dart
diff --git a/sdk/lib/_internal/pub/lib/src/command/run.dart b/sdk/lib/_internal/pub/lib/src/command/run.dart
new file mode 100644
index 0000000000000000000000000000000000000000..87f0d3bf339815812cafee6c72796ec9be43559b
--- /dev/null
+++ b/sdk/lib/_internal/pub/lib/src/command/run.dart
@@ -0,0 +1,83 @@
+// Copyright (c) 2014, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+library pub.command.run;
+
+import 'dart:async';
+import 'dart:io';
+
+import 'package:barback/barback.dart';
+
+import '../barback/asset_environment.dart';
+import '../command.dart';
+import '../exit_codes.dart' as exit_codes;
+import '../io.dart';
+import '../log.dart' as log;
+import '../utils.dart';
+
+final _arrow = getSpecial('\u2192', '=>');
+
+/// Handles the `run` pub command.
+class RunCommand extends PubCommand {
+  bool get takesArguments => true;
+  bool get allowTrailingOptions => false;
+  String get description => "Run an executable from a package.";
+  String get usage => "pub run <executable> [args...]";
+
+  Future onRun() {
+    // We only want output from the command itself, not pub.
+    log.showError();

[nweiz, 2014/05/29 19:30:09]

I think we also want to see warnings.

How does this interact with the user explicitly passing --verbose?

[Bob Nystrom, 2014/05/30 18:17:47]

Done.
This overrides it. Changed it to only mute output if the user does not change
the verbosity.

Either way, it still mutes all pub logging once the spawned process is started.

+
+    AssetEnvironment environment;

[nweiz, 2014/05/29 19:30:09]

Nit: I don't like typing this, and I don't think it matches our style elsewhere.

[Bob Nystrom, 2014/05/30 18:17:47]

Oops, that was a mistake. I sometimes temporarily annotate locals to get
auto-complete to work.

+    return AssetEnvironment.create(entrypoint, BarbackMode.RELEASE,
+        WatcherType.NONE, useDart2JS: false)
+          .then((_environment) {
+      environment = _environment;
+
+      // Show in-progress errors, but not results. Those get handled
+      // implicitly by getAllAssets().

[nweiz, 2014/05/29 19:30:09]

What about barback logs? They should be integrated with pub's logging facilities
so they work with the test infrastructure and with --verbose, but we don't want
to silence them with log.showError.

[Bob Nystrom, 2014/05/30 18:17:47]

That should be handled by AssetEnvironment, which registers the barback logger.
The behavior here is the same as pub build/serve.

+      environment.barback.errors.listen((error) {
+        log.error(log.red("Build error:\n$error"));
+      });
+
+      return environment.serveDirectory("bin");
+    }).then((server) {
+      var command;
+      var args;
+      if (commandOptions.rest.isEmpty) {

[nweiz, 2014/05/29 19:30:09]

This feels weird to me. I get that it's nice to have just "pub run" do something
intuitive, but I really don't like that the user has to do something different
if they want to pass any args.

[Bob Nystrom, 2014/05/30 18:17:47]

Oops, I meant to delete this. You're exactly right. I was trying this out before
I went on vacation and then decided against it (for the same reason you say),
but forgot to remove this.

+        command = entrypoint.root.name;
+        args = [];
+      } else {
+        command = commandOptions.rest[0];
+        args = commandOptions.rest.skip(1).toList();
+      }
+
+      var scriptPath = "bin/$command.dart";

[nweiz, 2014/05/29 19:30:09]

Add a TODO to support commands in other directories.

Also, maybe throw an error if [command] contains a path separator, since that
behavior will change in the future.

[Bob Nystrom, 2014/05/30 18:17:47]

Done.
I'm planning to implement this pretty much immediately, so I don't think it's
worth checking for it now.

+
+      // Try to make sure the entrypoint script exists (or is generated) before
+      // we spawn the process to run it.
+      return environment.barback.getAssetById(
+          new AssetId(entrypoint.root.name, scriptPath)).then((_) {
+        return environment.getUrlsForAssetPath(scriptPath).then((urls) {
+          // Should only be bound to one port.
+          assert(urls.length == 1);
+
+          // The URL to the Dart entrypoint is the first argument.
+          args.insert(0, urls[0].toString());
+          return Process.start(Platform.executable, args);

[nweiz, 2014/05/29 19:30:09]

I think this should run in checked mode by default.

[Bob Nystrom, 2014/05/30 18:17:47]

Done.

+        }).then((process) {
+          // Wire up pub's pipes to the spawned process.

[nweiz, 2014/05/29 19:30:09]

File a bug against dart:io to support "exec()" on applicable platforms and add a
TODO to use it here. Manually piping the streams has several downsides, perhaps
most notably that [stdioType] will return inaccurate results in the inner
process, which means that programs can't safely use colorized output.

[Bob Nystrom, 2014/05/30 18:17:47]

I could be wrong, but I don't think we'd be able to use exec() here, even if
supported. We need pub to stick around so that it can continue to serve the Dart
files that the spawned VM imports.
:(

Can we work on that in a later patch? I agree this is pretty rudimentary. Added
a TODO to do something better.

[nweiz, 2014/06/10 20:20:18]

There's a trick to making it work, although we'll also need fork() which I
forgot to mention. We fork the process, serve the assets from the forked child,
and call exec in the parent process.

That said, any sort of process spawning will only work with HTTP imports, not
import hooks. Why aren't we just spawning an isolate here?

[Bob Nystrom, 2014/06/11 18:07:33]

I figured we're eventually want to support running non-Dart executables (shell
scripts, etc.) from other packages too, so spawning a process seemed more
amenable for that.

[nweiz, 2014/06/12 01:17:37]

Okay, but for Dart processes we'll definitely need to use isolates so we can
control the imports, right?

[Bob Nystrom, 2014/06/12 21:17:50]

Do you mean non-package absolute path imports?

The "package:" ones are handled here. Since we spawn it with an HTTP entrypoint,
all of the "package:" imports are resolved relative to that and bounce back to
pub so we can handle them.

[nweiz, 2014/06/12 21:22:53]

No, I mean any imports that go through barback.
For now, yes, but HTTP imports are going away. Why design towards them?

+          process.stderr.pipe(stderr);
+          process.stdout.pipe(stdout);
+          stdin.pipe(process.stdin);
+
+          return process.exitCode;
+        }).then(flushThenExit);
+      }).catchError((error) {
+        log.error("Could not find $scriptPath.");

[nweiz, 2014/05/29 19:30:09]

[log.fine] the (Chain-ified) stack trace as well.

[Bob Nystrom, 2014/05/30 18:17:47]

Done.

+        return flushThenExit(exit_codes.NO_INPUT);
+      }, test: (error) => error is AssetNotFoundException);

[nweiz, 2014/05/29 19:30:09]

Nit: I prefer using "if (error is! AssetNotFoundException)" in the body to using
[test]. It matches our style elsewhere and puts the condition closer to where it
would be if this were a try/catch.

[Bob Nystrom, 2014/05/30 18:17:47]

Done. I used "test:" because I think it maintains a better stack trace for
errors that aren't caught. Do you think that matters?

[nweiz, 2014/06/10 20:20:18]

[catchError] will retain the original stack trace if the original error is
re-thrown.

[Bob Nystrom, 2014/06/11 18:07:33]

TIL.

+    });
+  }
+}