Minimise transitive dependencies to a reasonable set about coverage HOT 8 CLOSED

@cbracken most of those dependencies come via analyzer, which comes via pkg/test

Otherwise, I don't think the set of runtime dependencies is that much greater...

from coverage.

Does coverage have to be a package dependency or can it also be used with pub global run?

from coverage.

It can be used via pub global run

On Mon, May 30, 2016 at 1:44 AM, Günter Zöchbauer [email protected]
wrote:

Does coverage have to be a package dependency or can it also be used with pub
global run?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#109 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AABCitFpHzdqUsGthWeNEa2IJSMgXR0Bks5qGqNQgaJpZM4IpgYW
.

from coverage.

@zoechi the way coverage is run (from srcs or via a binary snapshot) is a separate issue to the dependency issue. * (details on how we actually run dart binaries at bottom)

For background, internally absolutely everything is built hermetically from the ground up from source on every build/test/coverage run, all the way down to the Dart VM itself. Binaries (e.g. snapshots) are never checked in.

Blaze/Bazel is actually pretty clever and caches all build products across everyone's runs, so this works out to be pretty quick in practice. However, this means that on every commit, all build products in the transitive closure of reverse dependencies of the committed code are invalidated and need to be rebuilt. The worst case scenario for this is a change to something that blaze itself depends on; this transitively affects all code and build products and requires a lot of extra pain and special procedures as a result.

*If you're curious, pub run is not used internally: we generally run all VM tools via snapshots, which are built from source immediately before running them. pub run is convenient for desktop development but behaviour isn't hermetic, which leads to non-reproducible builds. The Blaze/Bazel rules do effectively the same job, hermetically. If you're curious, we're working with the Bazel team on open-sourcing the rules. An early version is here.

from coverage.

@kevmoo thanks for clarifying.

Ripped out the test dep and we're down to 10. That's still a lot, but the set looks a lot more reasonable:

args 0.13.4+2
async 1.11.0
collection 1.8.0
json_rpc_2 1.2.0 (2.0.1 available)
logging 0.11.3
path 1.3.9
pub_semver 1.2.4
source_span 1.2.2
stack_trace 1.6.5
vm_service_client 0.1.3

from coverage.

@cbracken, those actually look pretty decent.

from coverage.

@cbracken thanks for the info

from coverage.

Closing as ignoring test, things look pretty good.

from coverage.