cap julia version for probably-0.7-incompatible packages #685

StefanKarpinski · 2018-08-23T07:38:55Z

This is a heuristic so definitely imperfect, but follows this reasoning about each versions julia compatibility version set:

has interval only containing 0.7+ versions => 0.7 compatible
supports an julia ≤ 0.6 & doesn't use Compat => 0.7 incompatible
claims to support 0.7+ & tagged on July 14 or later => 0.7 compatible
passes PkgEval => 0.7 compatible
otherwise => 0.7 incompatible

KristofferC · 2018-08-23T07:58:58Z

Is it possible to rebase this on top of #554 (which has some other fixes, for example the 1.1 julia dummy release which is needed) or merge them somehow. #554 also has updated shamaps but these are much more extensive than the ones here for some reason.

The heruistic seems reasonable to me. Would be interesting to see the diff in the registry this produces.

StefanKarpinski · 2018-08-23T13:27:24Z

Sure, I’ll rebase and can post the registry diff as a gist—it’s quite large. I just ran the update script against an up-to-date copy of the metadata repo.

StefanKarpinski · 2018-08-23T14:09:34Z

Rebasing master of Pkg onto that branch is causing a ton of conflicts that are totally unrelated to this PR. I guess I should just cherry-pick this change on top of that branch?

KristofferC · 2018-08-23T14:12:24Z

Yeah, the branch is very outdated so easiest to cherry-pick the commit from that branch here (which is an updated branch). Either your commit first or the one in that PR, whichever is easiest.

StefanKarpinski · 2018-08-23T14:30:12Z

This doesn't really work since I can't get the git metadata updates to cherry-pick over and I'm just not willing to spend another three days waiting for those to update. We really need to be propagating git metadata updates back to master so that this doesn't take so long every time it needs to be updated. This branch works as-is and has up-to-date git metadata TOML files; I have no idea what the best way to integrate that with the out-of-date update branch is.

KristofferC · 2018-08-23T14:31:57Z

Let me try then

KristofferC · 2018-08-23T14:35:45Z

Aha, you pushed an update to the shamaps to master. Ok, we can just ignore the maps in that PR then.

With the exception of julia since updating julia in the shamap was disabled with

Pkg.jl/bin/gitmeta.jl

Line 64 in d123b48

(pkg == "julia" || isempty(p.versions)) && continue

martinholters · 2018-08-24T09:37:30Z

Maybe also

has explicit upper bound => just trust the given bound

Or is that implicitly done right now? (I didn't check the code.)

StefanKarpinski · 2018-08-24T19:35:49Z

Updated with @martinholters's suggestion. Here's a gist of the registry diff:

https://gist.github.com/StefanKarpinski/b9df8cc7eb9eca8f02a73e6a9d08a888

StefanKarpinski · 2018-08-24T19:41:05Z

I also cherry-picked @KristofferC's update commit into there before the substantive changes here.

KristofferC · 2018-08-24T20:02:12Z

I'll deploy this, run it manually and open the changes as a PR so we can look at it with GitHub diff interface before committing to it.

PR: JuliaRegistries/General#16

KristofferC · 2018-08-24T20:47:40Z

This caps https://github.com/JuliaGraphics/Measures.jl which passes tests on 1.0 and is a dependency of Plots. Hmm.

StefanKarpinski · 2018-08-25T23:24:24Z

I've uncapped the maximum version of any package that's passing PkgEval.

lobingera · 2018-08-26T08:23:07Z

@StefanKarpinski Do i read correctly, that the list of passing on PkgEval is hardcoded? Where is the reference?

KristofferC · 2018-08-26T15:55:35Z

Dynamically loading it doesn't have an advantage because any package that starts to pass tests will have a new tag and thus won't be capped.

KristofferC · 2018-08-26T16:14:58Z

bin/loadmeta.jl

@@ -174,6 +174,7 @@ const date_cutoff = 1531526400 # July 14, 2018
 const all_vers = julia_versions()
 const old_vers = julia_versions(v -> v < v"0.7")
 const meta_dir = Pkg.Pkg2.dir("METADATA")
+const passing = readlines("bin/passing.txt")


joinpath(@__DIR__, "passing.txt").

KristofferC · 2018-08-26T16:45:37Z

Arguably, this should be capped to 0.7 upper bound instead of 0.6 since 0.7 should have deprecations in place?

KristofferC · 2018-08-26T20:12:03Z

Things like WriteVTK now get capped which does pass test because, going along the dependency chain, TranscodingStreams fails tests which is a dependency, so WriteVTK gets skipped.

Also, this seems to cap PyPlot. That doesn't seem right?

StefanKarpinski · 2018-08-26T21:01:03Z

So you think anything that’s not failing should not be capped? It seems to me that only packages that are actually passing should be exempt from capping logic. If a package is skipped we don’t know if it should be capped or not the heuristic should apply.

KristofferC · 2018-08-26T21:04:54Z

Yeah, I'm just saying it is unfortunate that we cap working packages. Of course, it is a heuristic so that might happen, but we should try to keep that to a minimum.

StefanKarpinski · 2018-08-26T21:29:59Z

There’s going to be some initial issues—they can be fixed by putting explicit correct caps on the packages.

KristofferC · 2018-08-27T06:09:35Z

Could we run a pkgeval that just test all packages without doing the while "skipped" part. Many packages fail because their test code does something quirky but work fine with normal usage. They then block a bunch of working palette from getting tested.

StefanKarpinski · 2018-08-27T17:10:58Z

@Keno could you do a PkgEval run like this so that we can get things capped?

Keno · 2018-08-27T17:33:50Z

sure

StefanKarpinski · 2018-09-12T21:47:11Z

So what's the path forward here? Can I get a list of packages I should whitelist?

KristofferC · 2018-09-12T21:55:23Z

The path forward here is to have a heuristic that doesn't recursively make most package uninstallable (like capping BinaryProvider would do).

I am guessing BinaryProvider gets capped because it has julia 0.7-rc3 in its REQUIRE and the v < v"0.7" check becomes true?

Then we need to generate a list like https://gist.github.com/KristofferC/6ef88542178e143fa9dc840fc1e13749 except also include recursively what packages are no longer installable and see that that list is not completely crazy.

StefanKarpinski · 2018-09-13T04:42:01Z

@Keno, can you help us get such a list. Given a list, I can put it in here and we can finally cap.

KristofferC · 2018-09-13T18:05:32Z

Hm, I think you missunderstood what list I meant (since you are asking Keno for help).

The list is just meant as a check that our cappening isn't effectively capping the whole ecosystem. The current heuristic does so by capping BinaryBuilder due to the likely "bug" that I mentioned in the previous post with the RC in REQUIRE.

So what we need to go ahead with this is a list of packages that are no longer installable by using Pkg.add (either because they are getting capped or a dependency of them is getting capped), manually look at that list and see that it is ok.

StefanKarpinski · 2018-09-13T18:27:11Z

If I have a list of the packages that we believe to already be work, then I whitelist them and make sure their latest version is considered compatible. That's already how this works: there's an explicit whitelist that I was given in JSON format. There's no more tweaking of this heuristic that can really be done.

martinholters · 2018-09-14T08:42:25Z

But are there any packages that do not get capped themselves, but become uninstallable because any of their dependencies get capped? If there are many, that might indicate a serious problem. If there are few, that might warrant a little more manual whitelisting.

KristofferC · 2018-09-14T14:28:51Z

But are there any packages that do not get capped themselves, but become uninstallable because any of their dependencies get capped? If there are many, that might indicate a serious problem.

Yes, we need to have such a list to evaluate the full impact this would have.

codecov-io · 2018-09-18T22:01:40Z

Codecov Report

Merging #685 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #685   +/-   ##
=======================================
  Coverage   91.92%   91.92%           
=======================================
  Files          17       17           
  Lines        2959     2959           
=======================================
  Hits         2720     2720           
  Misses        239      239

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80d9ba2...2e87b94. Read the comment docs.

codecov-io · 2018-09-18T22:01:53Z

Codecov Report

Merging #685 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #685   +/-   ##
=======================================
  Coverage   91.92%   91.92%           
=======================================
  Files          17       17           
  Lines        2959     2959           
=======================================
  Hits         2720     2720           
  Misses        239      239

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80d9ba2...2e87b94. Read the comment docs.

StefanKarpinski · 2018-09-18T22:04:23Z

I just spent several hours trying to understand why BinaryProvider gets capped. But it does not actually get capped. Old versions of BinaryProvider get capped, but newer ones don't.

StefanKarpinski · 2018-09-18T22:23:58Z

Based on the old "passing" list, PyPlot and YAML were the only dependencies that were not marked as passing but which are dependencies of packages that are.

this affects a whopping grand total of three packages

StefanKarpinski · 2018-09-18T22:35:47Z

Now the dependencies of passing packages are also marked as passing, which affected a whopping grand total of three packages.

codecov-io · 2018-09-18T22:57:22Z

Codecov Report

Merging #685 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #685   +/-   ##
=======================================
  Coverage   91.92%   91.92%           
=======================================
  Files          17       17           
  Lines        2959     2959           
=======================================
  Hits         2720     2720           
  Misses        239      239

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80d9ba2...f9093bf. Read the comment docs.

codecov-io · 2018-09-18T22:57:26Z

Codecov Report

Merging #685 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #685   +/-   ##
=======================================
  Coverage   91.92%   91.92%           
=======================================
  Files          17       17           
  Lines        2959     2959           
=======================================
  Hits         2720     2720           
  Misses        239      239

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80d9ba2...f9093bf. Read the comment docs.

codecov-io · 2018-09-18T22:57:33Z

Codecov Report

Merging #685 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #685   +/-   ##
=======================================
  Coverage   91.92%   91.92%           
=======================================
  Files          17       17           
  Lines        2959     2959           
=======================================
  Hits         2720     2720           
  Misses        239      239

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80d9ba2...f9093bf. Read the comment docs.

StefanKarpinski force-pushed the sk/cap-0.7 branch from 6c865ea to 4f0c49e Compare August 24, 2018 19:35

StefanKarpinski force-pushed the sk/cap-0.7 branch 2 times, most recently from c7ad386 to 1739b2b Compare August 25, 2018 23:23

KristofferC mentioned this pull request Aug 26, 2018

Add disclaimer banner JuliaLang/www.julialang.org#169

Closed

KristofferC reviewed Aug 26, 2018

View reviewed changes

StefanKarpinski closed this Aug 26, 2018

StefanKarpinski reopened this Aug 26, 2018

StefanKarpinski force-pushed the sk/cap-0.7 branch 2 times, most recently from c854ae5 to 2e87b94 Compare September 18, 2018 21:46

StefanKarpinski and others added 8 commits September 18, 2018 18:34

yet another sha1map update

2aef43d

Julia versions: real 0.7 commit; add 1.0 commit

f242ffe

updates

0a41838

more updates

98b30bc

cap julia version for probably-0.7-incompatible packages

c8d9444

take closed intervals at face value

ae1c471

don't cap max version of packages passing pkgeval

3be0456

deps of a passing packages also considered passing

f9093bf

this affects a whopping grand total of three packages

StefanKarpinski force-pushed the sk/cap-0.7 branch from 2e87b94 to f9093bf Compare September 18, 2018 22:35

StefanKarpinski merged commit 50da0ef into master Sep 19, 2018

bors bot deleted the sk/cap-0.7 branch September 19, 2018 16:04

This was referenced Sep 19, 2018

Tag a new release simonster/Reexport.jl#18

Closed

no julia 0.7 compatibility ? JuliaData/Missings.jl#90

Closed

cap julia version for probably-0.7-incompatible packages #685

cap julia version for probably-0.7-incompatible packages #685

Conversation

StefanKarpinski commented Aug 23, 2018 • edited by KristofferC Loading

KristofferC commented Aug 23, 2018 • edited Loading

StefanKarpinski commented Aug 23, 2018

StefanKarpinski commented Aug 23, 2018

KristofferC commented Aug 23, 2018

StefanKarpinski commented Aug 23, 2018 • edited Loading

KristofferC commented Aug 23, 2018

KristofferC commented Aug 23, 2018 • edited Loading

martinholters commented Aug 24, 2018

StefanKarpinski commented Aug 24, 2018

StefanKarpinski commented Aug 24, 2018

KristofferC commented Aug 24, 2018 • edited Loading

KristofferC commented Aug 24, 2018

StefanKarpinski commented Aug 25, 2018

lobingera commented Aug 26, 2018

KristofferC commented Aug 26, 2018

KristofferC Aug 26, 2018

Choose a reason for hiding this comment

KristofferC commented Aug 26, 2018

KristofferC commented Aug 26, 2018

StefanKarpinski commented Aug 26, 2018

KristofferC commented Aug 26, 2018

StefanKarpinski commented Aug 26, 2018

KristofferC commented Aug 27, 2018

StefanKarpinski commented Aug 27, 2018

Keno commented Aug 27, 2018

StefanKarpinski commented Sep 12, 2018

KristofferC commented Sep 12, 2018

StefanKarpinski commented Sep 13, 2018

KristofferC commented Sep 13, 2018

StefanKarpinski commented Sep 13, 2018

martinholters commented Sep 14, 2018

KristofferC commented Sep 14, 2018 • edited Loading

codecov-io commented Sep 18, 2018

Codecov Report

codecov-io commented Sep 18, 2018

Codecov Report

StefanKarpinski commented Sep 18, 2018

StefanKarpinski commented Sep 18, 2018

StefanKarpinski commented Sep 18, 2018

codecov-io commented Sep 18, 2018

Codecov Report

codecov-io commented Sep 18, 2018

Codecov Report

codecov-io commented Sep 18, 2018

Codecov Report

StefanKarpinski commented Aug 23, 2018 •

edited by KristofferC

Loading

KristofferC commented Aug 23, 2018 •

edited

Loading

StefanKarpinski commented Aug 23, 2018 •

edited

Loading

KristofferC commented Aug 23, 2018 •

edited

Loading

KristofferC commented Aug 24, 2018 •

edited

Loading

KristofferC commented Sep 14, 2018 •

edited

Loading