Debugging forced package downgrade

This happens occasionally: I have an env with 10-20 deps, one of the package’s latest version is 0.x.4 and I currently have 0.x.1; doing up doesn’t change anything. Forcing with add thePackage@0.x.4 leads to

 ├─possible versions are: [...0.x.1] or uninstalled
 └─restricted to versions 0.x.4 by an explicit requirement — no versions left

(and no additional information so it’s not one of those “remove this package and try again” situation).

Two questions:

  • any idea why this could happen? Shouldn’t patch release always be ok unless some package explicitly has a compat <= 0.x.1 which, in this case, is unlikely (at least I’ve not been able to find any such)
  • how do you debug such stuff when you have no pointer as to what package might be causing the block?


(for a concrete example:

(myEnv) pkg> add CSV@0.7.3
  Resolving package versions...
ERROR: Unsatisfiable requirements detected for package CSV [336ed68f]:
 CSV [336ed68f] log:
 ├─possible versions are: [0.3.0-0.3.1, 0.4.0-0.4.3, 0.5.0-0.5.26, 0.6.0-0.6.2, 0.7.0-0.7.1] or uninstalled
 └─restricted to versions 0.7.3 by an explicit requirement — no versions left

Edit: ended up going with deleting .julia/registries/General :confused:

Maybe you need to run update first, since the package manager does not seem to be aware of the latest version of CSV

I did run update (several times) as well as the add CSV@...