Support activating packages from local paths.

sdk/lib/_internal/pub/test/global/activate/does_not_install_dependencies_for_path_test.dart

Index: sdk/lib/_internal/pub/test/global/activate/does_not_install_dependencies_for_path_test.dart
diff --git a/sdk/lib/_internal/pub/test/global/activate/does_not_install_dependencies_for_path_test.dart b/sdk/lib/_internal/pub/test/global/activate/does_not_install_dependencies_for_path_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..4def91b1fe51ae35d41735dc4df6150b6b748d88
--- /dev/null
+++ b/sdk/lib/_internal/pub/test/global/activate/does_not_install_dependencies_for_path_test.dart
@@ -0,0 +1,25 @@
+// 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.
+
+import 'package:scheduled_test/scheduled_test.dart';
+
+import '../../descriptor.dart' as d;
+import '../../test_pub.dart';
+
+main() {
+  initConfig();
+  integration('activating a path package does not install dependencies', () {
+    d.dir("foo", [
+      d.libPubspec("foo", "1.0.0", deps: {
+        "bar": "any"
+      }),
+      d.dir("bin", [
+        d.file("foo.dart", "main() => print('ok');")
+      ])
+    ]).create();
+
+    schedulePub(args: ["global", "activate", "--source", "path", "../foo"],
+        output: "Activated foo 1.0.0.");

[nweiz, 2014/07/31 20:01:54]

This doesn't seem like the behavior users would want. It seems like, if the
dependencies haven't yet been installed for a path package, they should be when
that package is activated.

[Bob Nystrom, 2014/08/04 23:41:51]

When you activate a package at a path, it relies on the lock file in that
directory. I felt like implicitly running pub get in *that* directory when you
want pub global activate wasn't the behavior users would expect, but if we don't
do that, we can't install the dependencies.

In practice, I don't think it matters much: most users activating a package at a
path will already have a lockfile which implies they'll already have the
dependencies. If they don't, pub global run *will* implicitly run pub get.

I think it's useful for pub global activate to eagerly pull down dependencies
when you activate remote (hosted/git) packages because you may be about to go
offline. But for path packages, you probably have the deps already and/or know
what you're doing, so it's less important to do the get eagerly.

You're right that this is a semantically strange corner case. I added this test
specifically to track the current behavior since I didn't realize it at first
either. If you think it makes sense to implicitly run pub get on the activated
directory, I could be persuaded.

[nweiz, 2014/08/05 19:14:42]

I think it does. Think about what happens with the current behavior if you run
"pub global run" after activating a path package. Either it will install the
dependencies before running, in which case that's very similar to just
installing them eagerly when the package is activated; or it will break due to
lack of dependencies, which really hoses the use case of installing a package
from a tarfile (or whatever).

[Bob Nystrom, 2014/08/06 20:21:14]

I'm convinced. I realized that pub build and serve will implicitly run pub
get--including overwriting your lockfile too--so it doesn't seem inconsistent to
do so here.

Done.

+  });
+}