Package stuck at old version

I’m confused and frustrated. I was beginning to think that I understood the package system. It seems reasonable and rational. However, I’m completely puzzled why I seem to be perpetually stuck on Gadfly v 1.0.1 when v1.1.0 (and a couple of intermediate releases) are available. I haven’t pinned to v.1.0.1. I’ve updated all my packages. I’ve removed Gadfly and reinstalled it. In fact, I uninstalled all previous versions of Julia, deleted the “.julia” directory and installed “Julia 1.3.1” afresh and then reinstalled all the packages fresh. Nothing seems to work.
Could it be:

  • A Windows issue?
  • A Gadfly issue?
  • Another package is holding Gadfly back?
  • The latest version that supports Windows is 1.0.1?
  • ???

Insight would be gratefully appreciated.


I tried it and got the following:

  1. Gadfly not installed
  2. (v1.3) pkg> add Gadfly
    [c91e804a] + Gadfly v1.0.1
  3. (v1.3) pkg> up
    [c91e804a] ↑ Gadfly v1.0.1 ⇒ v1.1.0

So I had to do an additional update step to have version 1.1.0

If you explicitly

pkg> add Gadfly@1.1.0

the package manager should tell you if there’s another package holding you back from upgrading.


Thanks, this seems to identify the problem. Distributions seems to at 0.21.9 but Gadfly only support up to 0.20.0. When I try to downgrade Distributions to 0.20.0 Pkg complains that StatsBase is an issue. I think I’ll have to issue a pull request to update Gadfly to support 0.21.9.

This explains a lot. I’ve noticed that “updating” in Julia is like the stock market. The trend is generally up but along the way there also seem to be a number of dips - packages that are downgraded. I assumed the dips were packages pulling back on over-zealous releases but it seems also that they result from trying to install a package that doesn’t yet support the current version. I seem to have been stuck in version hell where one package required one version and another didn’t support it. On one hand, you don’t want your package to be used with dependencies that haven’t been tested. On the other hand, your package can cause others to be downgraded - potentially reintroducing bugs.
This seems like a significant issue with the current package manager’s design.

1 Like

I have created an environment (GadflyLatest) and added first Gadfly than Distributions which leads to:

(GadflyLatest) pkg> st
    Status `C:\Users\Oli\.julia\environments\GadflyLatest\Project.toml`
  [31c24e10] Distributions v0.20.0
  [c91e804a] Gadfly v1.1.0

It seems to work.
Maybe this is an option for you. Read about environments here:


This is intentional: the design of the package manager favors an environment that is composed of compatible packages (explicitly declared), and only upgrades when this can be maintained. The discussion starting here is worth reading:

In the long run, this should be solved by tooling (eg CompatHelper).

1 Like

Thanks. I will have to investigate environments.

I’m having the same problem, can someone help interpret the following message:

(v1.3) pkg> add Gadfly@1.1.0
Resolving package versions…
ERROR: Unsatisfiable requirements detected for package Gadfly [c91e804a]:
Gadfly [c91e804a] log:
├─possible versions are: [0.8.0, 1.0.0-1.0.1, 1.1.0] or uninstalled
├─restricted to versions 1.1.0 by an explicit requirement, leaving only versions 1.1.0
└─restricted by compatibility requirements with JSON [682c06a0] to versions: [0.8.0, 1.0.0-1.0.1] or uninstalled — no versions left
└─JSON [682c06a0] log:
├─possible versions are: [0.18.0, 0.19.0, 0.20.0, 0.21.0] or uninstalled
└─restricted to versions 0.21.0 by an explicit requirement, leaving only versions 0.21.0

I fought the JSON requirement too. I suspect that another (unspecified) package is insisting on JSON 0.21.0 and only 0.21.0. Gadfly 1.1.0 doesn’t yet support 0.21.0 so you can’t install Gadfly unless you remove the other package and downgrade JSON. (Gadfly in the repo does so you could update to the repo version.) This seems to be a problem with the way semantic version is being used. If 0.21.0 was instead 0.2.1 then Gadfly could add 0.2 to their compatibility list and be reasonably confident that 0.2.1 wouldn’t break something from 0.2.0.
I saw a thread awhile ago suggesting that developers should update stable packages to 1.0.0+ to make better use of semantic versioning. This is, I suspect, an example of the problems caused by maintaining sub-1 versions and not taking advantage of the breaking/non-breaking syntax within semantic versioning.