Plot size changes depending on installed packages

ForceBru · August 26, 2021, 10:47pm

I have two Pluto notebooks that are identical except for the line with imports. Yet the plot in the second one is consistently tiny.

Notebook with tiny plot

First like: using StatsPlots, Distributions, LoopVectorization, PlutoUI

Notebook with correct plot

First line: using StatsPlots#, Distributions, LoopVectorization, PlutoUI

My investigation

It turns out that the notebook with the tiny plot has different versions of packages that have to do with plotting. See diff of Pluto’s .jl files.

For example:

Part of correct plot Manifest

[[deps.Cairo_jll]]
deps = ["Artifacts", "Bzip2_jll", "Fontconfig_jll", "FreeType2_jll", "Glib_jll", "JLLWrappers", "LZO_jll", "Libdl", "Pixman_jll", "Pkg", "Xorg_libXext_jll", "Xorg_libXrender_jll", "Zlib_jll", "libpng_jll"]
git-tree-sha1 = "e2f47f6d8337369411569fd45ae5753ca10394c6"
uuid = "83423d85-b0ee-5818-9007-b63ccbeb887a"
version = "1.16.0+6"

[[deps.FFMPEG_jll]]
deps = ["Artifacts", "Bzip2_jll", "FreeType2_jll", "FriBidi_jll", "JLLWrappers", "LAME_jll", "LibVPX_jll", "Libdl", "Ogg_jll", "OpenSSL_jll", "Opus_jll", "Pkg", "Zlib_jll", "libass_jll", "libfdk_aac_jll", "libvorbis_jll", "x264_jll", "x265_jll"]
git-tree-sha1 = "3cc57ad0a213808473eafef4845a74766242e05f"
uuid = "b22a6f82-2f65-5046-a5b2-351ab43fb4e5"
version = "4.3.1+4"

[[deps.Fontconfig_jll]]
deps = ["Artifacts", "Bzip2_jll", "Expat_jll", "FreeType2_jll", "JLLWrappers", "Libdl", "Libuuid_jll", "Pkg", "Zlib_jll"]
git-tree-sha1 = "35895cf184ceaab11fd778b4590144034a167a2f"
uuid = "a3f928ae-7b40-5064-980b-68af3947d34b"
version = "2.13.1+14"

[[deps.FreeType2_jll]]
deps = ["Artifacts", "Bzip2_jll", "JLLWrappers", "Libdl", "Pkg", "Zlib_jll"]
git-tree-sha1 = "cbd58c9deb1d304f5a245a0b7eb841a2560cfec6"
uuid = "d7e528f0-a631-5988-bf34-fe36492bcfd7"
version = "2.10.1+5"

[[deps.GR]]
deps = ["Base64", "DelimitedFiles", "GR_jll", "HTTP", "JSON", "Libdl", "LinearAlgebra", "Pkg", "Printf", "Random", "Serialization", "Sockets", "Test", "UUIDs"]
git-tree-sha1 = "182da592436e287758ded5be6e32c406de3a2e47"
uuid = "28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71"
version = "0.58.1"

[[deps.GR_jll]]
deps = ["Artifacts", "Bzip2_jll", "Cairo_jll", "FFMPEG_jll", "Fontconfig_jll", "GLFW_jll", "JLLWrappers", "JpegTurbo_jll", "Libdl", "Libtiff_jll", "Pixman_jll", "Pkg", "Qt5Base_jll", "Zlib_jll", "libpng_jll"]
git-tree-sha1 = "d59e8320c2747553788e4fc42231489cc602fa50"
uuid = "d2c73de3-f751-5644-a686-071e5b155ba9"
version = "0.58.1+0"

Part of tiny plot Manifest

[[deps.Cairo_jll]]
deps = ["Artifacts", "Bzip2_jll", "Fontconfig_jll", "FreeType2_jll", "Glib_jll", "JLLWrappers", "LZO_jll", "Libdl", "Pixman_jll", "Pkg", "Xorg_libXext_jll", "Xorg_libXrender_jll", "Zlib_jll", "libpng_jll"]
git-tree-sha1 = "f2202b55d816427cd385a9a4f3ffb226bee80f99"
uuid = "83423d85-b0ee-5818-9007-b63ccbeb887a"
version = "1.16.1+0"

[[deps.FFMPEG_jll]]
deps = ["Artifacts", "Bzip2_jll", "FreeType2_jll", "FriBidi_jll", "JLLWrappers", "LAME_jll", "Libdl", "Ogg_jll", "OpenSSL_jll", "Opus_jll", "Pkg", "Zlib_jll", "libass_jll", "libfdk_aac_jll", "libvorbis_jll", "x264_jll", "x265_jll"]
git-tree-sha1 = "d8a578692e3077ac998b50c0217dfd67f21d1e5f"
uuid = "b22a6f82-2f65-5046-a5b2-351ab43fb4e5"
version = "4.4.0+0"

[[deps.Fontconfig_jll]]
deps = ["Artifacts", "Bzip2_jll", "Expat_jll", "FreeType2_jll", "JLLWrappers", "Libdl", "Libuuid_jll", "Pkg", "Zlib_jll"]
git-tree-sha1 = "21efd19106a55620a188615da6d3d06cd7f6ee03"
uuid = "a3f928ae-7b40-5064-980b-68af3947d34b"
version = "2.13.93+0"

[[deps.FreeType2_jll]]
deps = ["Artifacts", "Bzip2_jll", "JLLWrappers", "Libdl", "Pkg", "Zlib_jll"]
git-tree-sha1 = "87eb71354d8ec1a96d4a7636bd57a7347dde3ef9"
uuid = "d7e528f0-a631-5988-bf34-fe36492bcfd7"
version = "2.10.4+0"

[[deps.GR]]
deps = ["Base64", "DelimitedFiles", "HTTP", "JSON", "LinearAlgebra", "Printf", "Random", "Serialization", "Sockets", "Test", "UUIDs"]
git-tree-sha1 = "cd0f34bd097d4d5eb6bbe01778cf8a7ed35f29d9"
uuid = "28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71"
version = "0.52.0"

Summary

The two files differ by their first line:

Correct plot:
using StatsPlots#, Distributions, LoopVectorization, PlutoUI
- last three packages are commented out!
Tiny plot:
using StatsPlots, Distributions, LoopVectorization, PlutoUI

The two files have different versions of packages installed:

Cairo_jll
- Correct plot: v1.16.0+6
- Tiny plot: v1.16.1+0
FFMPEG_jll
- Correct plot: v4.3.1+4
- Tiny plot: v4.4.0+0
Fontconfig_jll
- Correct plot: v2.13.1+14
- Tiny plot: v2.13.93+0
…and so on

Question

What’s going on???! How did importing the other three packages influence the lower-level tooling? Importing StatsPlots alone installed Cairo 1.16.0+6, but importing the other three packages suddenly upgraded Cairo to 1.16.1+0?!

Even worse, the upgraded versions produced the buggy tiny plot.

Is it possible to import the 4 packages together without… breaking plotting?

julia> versioninfo()
Julia Version 1.7.0-beta3.0
Commit e76c9dad42 (2021-07-07 08:12 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin18.7.0)
  CPU: Intel(R) Core(TM) i5-3330S CPU @ 2.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.0 (ORCJIT, ivybridge)

ForceBru · August 26, 2021, 11:05pm

Same thing on Julia 1.6:

Julia Version 1.6.2
Commit 1b93d53fc4 (2021-07-14 15:36 UTC)

MCVE:

### A Pluto.jl notebook ###
# v0.15.1

using Markdown
using InteractiveUtils

# ╔═╡ 55b4f148-06b8-11ec-15dc-0b0ce01bbfed
using StatsPlots, Distributions, LoopVectorization, PlutoUI

# ╔═╡ 0c5f2446-e9f2-49d2-a483-1c07964e758c
md"# Bug present"

# ╔═╡ 77677e1e-a075-4103-b1b2-dbbfbc7482d3
plot(1:10000, label="", title="Log returns", linewidth=.4, fmt=:png)

# ╔═╡ e6437236-bf15-4807-aac8-2163639fba6a
plot(1:10, fmt=:png)

# ╔═╡ Cell order:
# ╠═55b4f148-06b8-11ec-15dc-0b0ce01bbfed
# ╟─0c5f2446-e9f2-49d2-a483-1c07964e758c
# ╠═77677e1e-a075-4103-b1b2-dbbfbc7482d3
# ╠═e6437236-bf15-4807-aac8-2163639fba6a

I wanted to post the full 1030-line(!!) Pluto notebook, but the forum didn’t let me (RIP reproducible research)

nilshg · August 27, 2021, 8:15am

I’m guessing your actual issue is with GR, not with the other dependencies, as that is the actual plotting backend you’re using and it’s at the (quite outdated) version 0.52 in your notebook with all packages installed.

Furthermore, it seems you’re running into a resolver ambiguity, where different possible “local optima” in terms of package configuration are possible. Consider an example where packages are added sequentially:

(@v1.7) pkg> activate --temp
  Activating new project at `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX`

(jl_iJqdAX) pkg> add StatsPlots
    Updating registry at `C:\Users\ngudat\.julia\registries\General.toml`
   Resolving package versions...
    Updating `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Project.toml` 
  [f3b207a7] + StatsPlots v0.14.26
(...)

(jl_iJqdAX) pkg> st -m GR
      Status `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Manifest.toml`
  [28b8d3ca] GR v0.58.1

(jl_iJqdAX) pkg> add Distributions
   Resolving package versions...
    Updating `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Project.toml`
  [31c24e10] + Distributions v0.25.13
  No Changes to `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Manifest.toml`

(jl_iJqdAX) pkg> st -m GR
      Status `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Manifest.toml`
  [28b8d3ca] GR v0.58.1

(jl_iJqdAX) pkg> add LoopVectorization
(...)

(jl_iJqdAX) pkg> add PlutoUI
(...)

(jl_iJqdAX) pkg> st -m GR
      Status `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Manifest.toml`
  [28b8d3ca] GR v0.58.1

so we’ve added all packages and ended up with GR at it’s current version 0.58.1. Now:

(jl_iJqdAX) pkg> rm StatsPlots Distributions LoopVectorization PlutoUI
(...)

(jl_iJqdAX) pkg> add StatsPlots Distributions LoopVectorization PlutoUI
   Resolving package versions...
    Updating `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Project.toml`
  [31c24e10] + Distributions v0.25.13
  [bdcacae8] + LoopVectorization v0.12.66
  [7f904dfe] + PlutoUI v0.7.9
  [f3b207a7] + StatsPlots v0.14.26

(jl_iJqdAX) pkg> st -m GR
      Status `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Manifest.toml`
  [28b8d3ca] GR v0.52.0

What’s going on here? Let’s update GR explicitly:

(jl_iJqdAX) pkg> up GR
    Updating registry at `C:\Users\ngudat\.julia\registries\General.toml`
  No Changes to `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Project.toml`
    Updating `C:\Users\ngudat\AppData\Local\Temp\jl_iJqdAX\Manifest.toml`
  [4fba245c] ↑ ArrayInterface v3.1.17 ⇒ v3.1.23
  [28b8d3ca] ↑ GR v0.52.0 ⇒ v0.58.1
  [5c1252a2] ↑ GeometryBasics v0.3.13 ⇒ v0.4.1
  [cd3eb016] ↑ HTTP v0.8.19 ⇒ v0.9.13
  [91a5bcdd] ↑ Plots v1.15.2 ⇒ v1.21.1
  [aedffcd0] ↑ Static v0.2.5 ⇒ v0.3.0
  [5c2747f8] + URIs v1.3.0
  [6e34b625] ↓ Bzip2_jll v1.0.8+0 ⇒ v1.0.6+5
  [83423d85] ↓ Cairo_jll v1.16.1+0 ⇒ v1.16.0+6
  [b22a6f82] ↓ FFMPEG_jll v4.4.0+0 ⇒ v4.3.1+4
  [a3f928ae] ↓ Fontconfig_jll v2.13.93+0 ⇒ v2.13.1+14
  [d7e528f0] ↓ FreeType2_jll v2.10.4+0 ⇒ v2.10.1+5
  [0656b61e] + GLFW_jll v3.3.5+0
  [d2c73de3] + GR_jll v0.58.1+0
  [3b182d85] - Graphite2_jll v1.3.14+0
  [2e76f6c2] - HarfBuzz_jll v2.8.1+0
  [aacddb02] + JpegTurbo_jll v2.1.0+0
  [dd192d2f] + LibVPX_jll v1.10.0+0
  [7e76a0d4] + Libglvnd_jll v1.3.0+3
  [89763e89] + Libtiff_jll v4.3.0+0
  [ea2cea3b] + Qt5Base_jll v5.15.3+0
  [a2964d1f] + Wayland_jll v1.19.0+0
  [2381bf8a] + Wayland_protocols_jll v1.18.0+4
  [935fb764] + Xorg_libXcursor_jll v1.2.0+4
  [d091e8ba] + Xorg_libXfixes_jll v5.0.3+4
  [a51aa0fd] + Xorg_libXi_jll v1.7.10+4
  [d1454406] + Xorg_libXinerama_jll v1.1.4+4
  [ec84b674] + Xorg_libXrandr_jll v1.5.2+4
  [cc61e674] + Xorg_libxkbfile_jll v1.1.0+4
  [12413925] + Xorg_xcb_util_image_jll v0.4.0+1
  [2def613f] + Xorg_xcb_util_jll v0.4.0+1
  [975044d2] + Xorg_xcb_util_keysyms_jll v0.4.0+1
  [0d47668e] + Xorg_xcb_util_renderutil_jll v0.3.9+1
  [c22f9ab0] + Xorg_xcb_util_wm_jll v0.4.1+1
  [35661453] + Xorg_xkbcomp_jll v1.4.2+4
  [33bec58e] + Xorg_xkeyboard_config_jll v2.27.0+4
  [3161d3a3] + Zstd_jll v1.5.0+0
  [0ac62f75] ↓ libass_jll v0.15.1+0 ⇒ v0.14.0+4
  [f638f0a6] ↓ libfdk_aac_jll v2.0.2+0 ⇒ v0.1.6+4
  [1270edf5] ↓ x264_jll v2021.5.5+0 ⇒ v2020.7.14+2
  [dfaa095f] ↓ x265_jll v3.5.0+0 ⇒ v3.0.0+3
  [d8fb68d0] + xkbcommon_jll v0.9.1+5

So you see having the most recent version of GR requires the downgrade of quite a few dependencies, and the upgrade of some others. It looks like the resolver picks the combination of packages with GR at version v0.52. Not sure how to deal with this in the Pluto version of the package manager, but you can always do using Pkg in the notebook to use the regular package manager and update GR.

Maybe @kristoffer.carlsson can comment on whether there’s anything that could be improved on the resolver side here, but it seems to me that there’s nothing really wrong here, as the resolver can’t really know that the user would prefer a version with the GR dependency at a later version and some others at a higher version.

ForceBru · August 27, 2021, 9:21am

Yes! I also noticed that putting using statements in different cells results in the correct plot, but putting everything on the same line messes it up.

the resolver can’t really know that the user would prefer a version with the GR dependency at a later version and some others at a higher version

Why not always install the newest version possible? If I ever want a specific previous version, I’ll explicitly tell Pkg to install that one version.

So what I’m seeing right now is that installing packages in a slightly different way might install different versions of dependencies (even though I never explicitly requested particular versions any package), which might change the behavior of my code. This very sentence sounds pretty ridiculous to me. I think this is highly unintuitive, to say the least.

Is it possible to predict this kind of situation? For example, Pkg could tell me something like “Hey, this command will install GR v0.1, but if you like swapped the order of the packages or something, that would install GR v0.58”

nilshg · August 27, 2021, 10:03am

As I’ve shown above, it isn’t possible - with GR at v0.58 you’re getting older versions of Bzip2_jll, Cairo_jll, FFMPEG_jll, Fontconfig_jll, libass_jll, libfdk_aac_jll, x264_jll, and x265_jll. There’s no way for the resolver to know that you are relying on a bug fix that’s present in GR 0.58 but not in 0.52, other uses might be relying on a bug fix or new feature that’s present in x264_jll version 2021.5.5, but wasn’t available in 2020.7.14. You therefore have to tell the resolver, which you can do by up GR or add GR@0.58.

So what I’m seeing right now is that installing packages in a slightly different way might install different versions of dependencies (even though I never explicitly requested particular versions any package), which might change the behavior of my code. This very sentence sounds pretty ridiculous to me. I think this is highly unintuitive, to say the least.

I’m not sure I would call this “ridiculous”, the fact of the matter is that you can’t have the latest version of all dependencies for the combination of packages you are using, so the resolver must pick one of mutiple possible combinations. Again @kristoffer.carlsson is better placed to comment on the details of the resolver, but I believe when you do add X Y Z it will take into account all packages jointly, while if you do add X followed by add Y, it will attempt to make as few changes as possible to the environment, which might indeed result in picking a different set of dependencies. It might be useful to document this somewhere (at least I can’t find it in the Pkg docs).

Is it possible to predict this kind of situation? For example, Pkg could tell me something like “Hey, this command will install GR v0.1, but if you like swapped the order of the packages or something, that would install GR v0.58”

I don’t see how this would be practical - your suggestion sounds to me like Pkg would have to test (at least) n! ways of adding n packages, each time inspecting the Manifest generated and present you with a list of all the differences between them.

ForceBru · August 28, 2021, 12:23pm

I stumbled upon this again, now with a different set of packages:

  [6e4b80f9] BenchmarkTools v1.1.4
  [aaaa29a8] Clustering v0.14.2
  [31c24e10] Distributions v0.25.14
  [bdcacae8] LoopVectorization v0.12.66
  [d949a032] MovingGaussianMixtures v0.3.0 `dev/MovingGaussianMixtures`
  [91a5bcdd] Plots v1.15.2
  [c46f51b8] ProfileView v0.6.10
  [92933f4c] ProgressMeter v1.7.1
  [295af30f] Revise v3.1.19
  [f3b207a7] StatsPlots v0.14.26
  [b8865327] UnicodePlots v2.0.0

Getting a tiny plot in Pluto again:

I upgraded GR manually, and the problem went away:

(VolatilityDecomposition) pkg> up GR
    Updating registry at `~/.julia/registries/General.toml`
   Installed GTK3_jll ── v3.24.29+0
   Installed Pango_jll ─ v1.42.4+10
   Installed GR ──────── v0.57.5
  Downloaded artifact: Pango
  Downloaded artifact: GTK3
  No Changes to `~/Desktop/VolatilityDecomposition/Project.toml`
    Updating `~/Desktop/VolatilityDecomposition/Manifest.toml`
  [4fba245c] ↑ ArrayInterface v3.1.17 ⇒ v3.1.23
  [28b8d3ca] ↑ GR v0.52.0 ⇒ v0.57.5
  [cd3eb016] ↑ HTTP v0.8.19 ⇒ v0.9.13
  [aedffcd0] ↑ Static v0.2.5 ⇒ v0.3.0
  [5c2747f8] + URIs v1.3.0
  [6e34b625] ↓ Bzip2_jll v1.0.8+0 ⇒ v1.0.6+5
  [83423d85] ↓ Cairo_jll v1.16.1+0 ⇒ v1.16.0+6
  [b22a6f82] ↓ FFMPEG_jll v4.4.0+0 ⇒ v4.3.1+4
  [a3f928ae] ↓ Fontconfig_jll v2.13.93+0 ⇒ v2.13.1+14
  [d7e528f0] ↓ FreeType2_jll v2.10.4+0 ⇒ v2.10.1+5
  [0656b61e] + GLFW_jll v3.3.5+0
  [d2c73de3] + GR_jll v0.58.1+0
  [77ec8976] ↓ GTK3_jll v3.24.30+0 ⇒ v3.24.29+0
  [dd192d2f] + LibVPX_jll v1.10.0+0
  [36c8627f] ↓ Pango_jll v1.47.0+0 ⇒ v1.42.4+10
  [ea2cea3b] + Qt5Base_jll v5.15.3+0
  [12413925] + Xorg_xcb_util_image_jll v0.4.0+1
  [2def613f] + Xorg_xcb_util_jll v0.4.0+1
  [975044d2] + Xorg_xcb_util_keysyms_jll v0.4.0+1
  [0d47668e] + Xorg_xcb_util_renderutil_jll v0.3.9+1
  [c22f9ab0] + Xorg_xcb_util_wm_jll v0.4.1+1
  [0ac62f75] ↓ libass_jll v0.15.1+0 ⇒ v0.14.0+4
  [f638f0a6] ↓ libfdk_aac_jll v2.0.2+0 ⇒ v0.1.6+4
  [1270edf5] ↓ x264_jll v2021.5.5+0 ⇒ v2020.7.14+2
  [dfaa095f] ↓ x265_jll v3.5.0+0 ⇒ v3.0.0+3
    Building GR → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/b83e3125048a9c3158cbb7ca423790c7b1b57bea/build.log`
Precompiling project...
  9 dependencies successfully precompiled in 81 seconds (202 already precompiled)

(VolatilityDecomposition) pkg>

Is there something I can do to prevent this kind of thing from happening? Should I maybe report this to the devs somewhere? However, as far as I understood from the comments above, this is expected to work this way… yet the older version of GR that gets installed automatically produces the buggy plot, so I guess it shouldn’t be installed, especially when a new version is available…

nilshg · August 28, 2021, 1:44pm

There’s still Distributions and LoopVectorization in there, so it’s probably exactly the same issue of GR relying on a set of dependencies that doesn’t fit with what the other two want. As I said above, there’s no way for the resolver to know that you care about the Bugfix in the newer GR version, but not about the bugfixes in the other dependencies that get downgraded when you force the update of GR

ForceBru · August 28, 2021, 3:19pm

Well, I guess I’ll just update GR manually whenever I stumble upon this. Thanks for your help, @nilshg!

ForceBru · August 31, 2021, 5:58pm

It’s me again, with my daily dose of weird downgraded packages!

I was trying to set up a NextJournal Julia runtime (Trying to build Julia environment for NextJournal - Nextjournal), but ran into the same issue, and again Distributions and LoopVectorization seem to be the culprits.

I downloaded a fresh julia-1.6.2-linux-x86_64.tar.gz from the Julia site

Then I attempted to install some packages:

julia -e 'using Pkg; pkg"up; add CSV DataFrames Distributions LoopVectorization BenchmarkTools; build; precompile"'

This attempted to install:
- CSV v0.4.0 (current version 0.8.5)
- DataFrames v0.19.4 (current version 1.2.2!)
- CategoricalArrays v0.6.0 (current version 0.9.7)
CSV, DataFrames and CategoricalArrays failed to precompile (see link above for error messages)

So, while the original issue (with tiny plots by Plots.jl) wasn’t critical (the plots were really small, but whatever - my code worked), this one straight up breaks things!

I managed to solve this by running Pkg.add("PackageName", preserve=PkgPRESERVE_NONE) for each package individually (again, see link to NextJournal)

nilshg · September 1, 2021, 7:40am

You’re running into this issue here:

So this will be fixed with the next CSV release, for now you can just do add DataFrames@1.2 explicitly which will force Parser back down to v1:

(jl_HyZX36) pkg> add DataFrames@1.2
   Resolving package versions...
    Updating `C:\Users\ngudat\AppData\Local\Temp\jl_HyZX36\Project.toml`
  [336ed68f] ↑ CSV v0.4.0 ⇒ v0.8.5        
  [a93c6f00] ↑ DataFrames v0.19.4 ⇒ v1.2.2
    Updating `C:\Users\ngudat\AppData\Local\Temp\jl_HyZX36\Manifest.toml`
  [336ed68f] ↑ CSV v0.4.0 ⇒ v0.8.5
  [324d7699] - CategoricalArrays v0.6.0
  [34da2185] ↑ Compat v2.2.1 ⇒ v3.34.0
  [a8cc5b0e] + Crayons v4.0.4
  [a93c6f00] ↑ DataFrames v0.19.4 ⇒ v1.2.2
  [9a8bc11e] - DataStreams v0.4.2
  [864edb3b] ↑ DataStructures v0.17.20 ⇒ v0.18.10
  [59287772] + Formatting v0.4.2
  [92d709cd] + IrrationalConstants v0.1.0
  [2ab3a3ac] ↑ LogExpFunctions v0.2.5 ⇒ v0.3.0
  [e1d29d7a] ↑ Missings v0.4.5 ⇒ v1.0.1
  [69de0a69] ↓ Parsers v2.0.3 ⇒ v1.1.2
  [2dfb63ee] ↑ PooledArrays v0.5.3 ⇒ v1.3.0
  [08abe8d2] + PrettyTables v1.1.0
  [189a3867] ↑ Reexport v0.2.0 ⇒ v1.2.2
  [91c51154] + SentinelArrays v1.3.7
  [a2af1166] ↑ SortingAlgorithms v0.3.1 ⇒ v1.0.1
  [4c63d2b9] ↑ StatsFuns v0.9.8 ⇒ v0.9.10
  [bd369af6] ↑ Tables v0.2.11 ⇒ v1.5.0
  [ea10d353] - WeakRefStrings v0.5.8
  [9abbd945] - Profile