Schematic Way to resolve dependency issues in a package development

General Usage
1

Yesterday I ran into a not-so nice situation with packages and their dependencies. I added a package or updated a package (after ] activate MyPackage an ] update) to my current development status and while locally on my machine everything ran smoothly (Julia 1.3) the CI (Julia 1.0, 1.2 and 1.3) did not respond so well. For example here

where the corresponding (currently checked in) Manifest reads

I noticed that the troubling package is OpenBLAS_jll which is (reverse lookup in said manifest) used by Arpack_jll which itself is required by Arpack which PDMats needs which (finally!) we need for Distributions.

So the version error stems from a dependency of a dependency of a dependency of a dependency that we need (huargh!). Just by chance I remmebererd that we had that before and it was updated in said update above, so I looked at an old Manifest(though I don’t like the Manifest being checked in, here it was nice) that for the previous Arpack it worked (0.3.2 instead of 0.4.0)

My solution was now to manually add Arpack to our dependencies (though it’s not directly needed by us) and fix it to 0.3.2, this downgrades a few packages in above said path but then the conflict is resolved…

Is there any nicer way to

  1. Find this then pure guessing and looking at old Manifests?

  2. a Nicer way to resolve this then to add a dependency and fix the version?
    Imagine Distributions finds something nicer and does not require Arpack anymore, with an update we would’t need it either but we currently have it fixed included just to keep a version that is running with CI (Julia 1.0 and 1.2 which we would like to also tyts against=?

2 Likes
2

Would everything be solved by not checking in the Manifest.toml?

1 Like
3

I tried that too, that did not work and was a few weeks ago the reson to commit it in the first place.

My question is more general: How does one resolve these – best without guess work but in a schematic way.

edit: especially I am not running into these problems locally (Julia 1.3 mac) while all CI (Julia 1.0, 1.2 & 1.3 on Linux) fail. That makes it also not that easy to find the problems.

1 Like
4

Bump?

It’s a rather annoying issue that seems to occur when test dependencies can’t be resolved without changing versions of direct dependencies (due to upper-bounding). Julia 1.4 seems to be able to recompute versions when test dependencies are added but not earlier versions.

I think we could try generating manifests with Julia 1.4.