We used to be storing packages from HTTP hosted sources in directories
named after the hostname. There was no distinction between a package
from an HTTP source and an HTTPS source with the same name. This was
contrary to the rest of pub's logic, which considered those different
sources.

Closes #1418

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//2028853002 .

If a path dependency had a dependency back on the root package, it
would be detected as always stale because the root package isn't in the
lockfile. This changes the check to always consider that fresh, since
all dependencies on the root package are satisfied.

Closes #1416

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1985063004 .

OfflineHostedSource was failing to parse the directory names for
prerelease package versions correctly.

Closes #1415

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1971523002 .

We no longer include overridden dependencies' constraints, since those
constraints aren't checked when doing version resolution. In the worst
case, including them caused us to generate invalid lockfiles with
"<empty>" as the SDK constraint.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1956613002 .

We had a logic error wherein we were checking dependencies only
for cached packages when we should have been checking them only
for *uncached* packages.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1956543002 .

This passes --format=ustar to the tar process on Linux and OS X, which
should prevent user-specific configuration from causing it to use the
PAX format which is incompatible with 7zip on Windows.

Closes #1411

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1920433002 .

R=nweiz@google.com

Review URL: https://codereview.chromium.org//1907023002 .

Closes #1405

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1892683002 .

This is necessary since the SDK's repo requires that.

R=kevmoo@google.com

Review URL: https://codereview.chromium.org//1902993003 .

BUG=https://github.com/dart-lang/sdk/issues/26295
BUG=https://github.com/dart-lang/pub/issues/1407
R=rnystrom@google.com

Review URL: https://codereview.chromium.org/1895423002 .

This was confusing browsers which ignore the ETag for XHRs and would
simply use the local cache for an asset even if it had changed on the
server.

R=sigmund@google.com

Review URL: https://codereview.chromium.org//1874623004 .

"git ls-files" doesn't natively resolve symlinks, so this adds some
logic to do so manually. This brings the behavior of uploading from a
Git repo in line with non-Git uploading.

We still don't have a multipart parser in Dart, so we unfortunately have
to way of writing automated tests that the tarballs are created as
expected. I did verify this behavior locally, though.

Closes #1400

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1862833002 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1863773003 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1852513004 .

Closes #1396

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1809993003 .

In my local tests, this has a negligible performance impact on packages
with lots of small files, but is helpful for large unchanged assets.

R=nweiz@google.com

Review URL: https://codereview.chromium.org//1790503005 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1765653002 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1726133002 .

Fix docs typos

Closes #1392

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1691573002 .

I forgot to update this to the new package server API, so it had a
future that was never completing.

Closes #1389
Closes #1390

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1674393002 .

Closes #1387

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1668983003 .

The hosted source was dropping these on the floor, causing non-default
hosted packages to fail to download.

Closes #1386

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1664903003 .

This sets the stage for adding tests for #1386.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1664563002 .

Closes #1382

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1590723005 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1585513002 .

Pub wasn't canonicalizing a path in the same way as the tests, which
caused a difference on the Windows bots.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1560393002 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1564653002 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1561743002 .

This got broken when the "sdk" field was added.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1557253002 .

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1556243002 .

Closes #1369

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1556043006 .

This considers the lockfile stale if the intersection of all selected
packages' SDK constraints don't match the current SDK, or if it contains
a path dependency whose own dependencies don't match the lockfile.

Closes #1091
Closes #1101

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1534093002 .

Closes #1368

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1555133002 .

Previously, many tests were generating a lockfile from whole cloth that
pointed to barback and its dependencies. This made it hard to improve
the heuristics for detecting when the lockfile was out-of-date (#1091
and #1101), since the generated lockfiles failed those heuristics.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1523323004 .

This also allows us to limit our tests to the latest barback, which
simplifies the necessary infrastructure and speeds up the tests
dramatically.

Closes #1367

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1530353002 .

This folds the distinction between "resolved" and "unresolved"
descriptions into the distinction between PackageIds and PackageRefs. In
other words, all PackageIds now have resolved descriptions and all
PackageRefs now have unresolved descriptions. This makes it easier to
track which descriptions are resolved and express resolution constraints
via the type system.

This also restricts the creation of PackageRefs and PackageIds to source
classes, which helps ensure that the description format—which is an
implementation detail—doesn't leak into surrounding code.

R=rnystrom@google.com

Review URL: https://codereview.chromium.org//1528523003 .

R=kevmoo@google.com

Review URL: https://codereview.chromium.org//1524953002 .