Use archiveUrl when specified.

[isoos]

• ListMixin.firstWhere at .downloadPackage  #1165
• I also think we should not implement Pana should use dart pub to download and extract packages.  #1170, as it also relies on the potentially cached version list.

[sigurdm]

I also think we should not implement Pana should use dart pub to download and extract packages. #1170, as it also relies on the potentially cached version list.

Not sure this is true if I read it right. pub doesn't rely on the cached version listings - only as a heuristic to speed up requesting version listings for transitive dependencies.

[sigurdm]

LGTM

[sigurdm]

Not sure this is true if I read it right. pub doesn't rely on the cached version listings - only as a heuristic to speed up requesting version listings for transitive dependencies.

Ah you were talking about the cached version listings on pub.dev - just forget what I wrote then.

[jonasfj]

Not sure this is true if I read it right. pub doesn't rely on the cached version listings - only as a heuristic to speed up requesting version listings for transitive dependencies.

Ah you were talking about the cached version listings on pub.dev - just forget what I wrote then.

@isoos I don't understand this concern. The dart pub client will rely on the same APIs as the downloadPackage method uses.

Do you mean that dart pub might reuse something already downloaded in PUB_CACHE?
I don't really see what is wrong with that?
Certainly not in the future where we run each package in it's own VM. It's unlikely that newer or older versions of the same package will depend on the same package, actually I'm not sure how that would happen.

But regardless of whether we could reuse something from PUB_CACHE; I don't see a problem with that. The PUB_CACHE is intended to be immutable, let's trust it to be. Or let's introduce something like dart pub cache purge <package>, if we really want it -- I don't think it's necessary.

[isoos]

@isoos I don't understand this concern. The dart pub client will rely on the same APIs as the downloadPackage method uses.

Exactly, and that is causing analysis failures right now. This PR allows us to feed the archiveUrl to pana without going through the cached API response.

The root cause of this issue is the cache: we receive a new version, but the cache may be stale for 10 minutes (either because we have split traffic or failed to purge it), during which any analysis that uses the API will fail for the new version.

[sigurdm]

Could we make some retry-logic in pana (or perhaps pub-worker) to take these possible 10 minutes into account?

• pub get
  • (wait 1 minute)
• pub get
  • (wait 2 minutes)
• pub get
  • (wait 3 minutes)
• pub get
  • (wait 4 minutes)
• pub get
  • give up.

...or something even more clever

[isoos]

I don't think pub get should have any minute+ retry. A few seconds may be okay for transient issues, but the process shouldn't hang for minutes just because there may be a cache invalidation down the line...

Coming from that angle, maybe this change is not needed either, instead, we should have a better retry logic on pub.dev, e.g. invalidating the cache if the first attempt of a latest version fails. (And do the second attempt after the cache has been invalidated.)

[isoos]

Closing this as we will land the cache purge instead.