# Schematic Way to resolve dependency issues in a package development

**URL:** <https://discourse.julialang.org/t/schematic-way-to-resolve-dependency-issues-in-a-package-development/33512>\
**Category:** General Usage\
**Created:** [January 18, 2020, 7:52am UTC](https://discourse.julialang.org/t/schematic-way-to-resolve-dependency-issues-in-a-package-development/33512 "2020-01-18T07:52:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [January 18, 2020, 7:52am UTC](https://discourse.julialang.org/t/schematic-way-to-resolve-dependency-issues-in-a-package-development/33512/1 "2020-01-18T07:52:18Z")

</div>

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

> **[Travis CI - Test and Deploy with Confidence](https://app.travis-ci.com/JuliaNLSolvers/Manifolds.jl/jobs/638552350?utm_medium=notification&utm_source=github_status)**
>
> Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.

where the corresponding (currently checked in) Manifest reads

> <https://github.com/JuliaManifolds/Manifolds.jl/blob/ff7515fbbcc6a463a69e7eb362d2ed3594dc1581/Manifest.toml>

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=?

---

<div class="post-metadata">

**Author:** ![thofma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thofma/32/1691_2.png) [@thofma](https://discourse.julialang.org/u/thofma)\
**Post date:** [January 18, 2020, 2:17pm UTC](https://discourse.julialang.org/t/schematic-way-to-resolve-dependency-issues-in-a-package-development/33512/2 "2020-01-18T14:17:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [January 18, 2020, 2:27pm UTC](https://discourse.julialang.org/t/schematic-way-to-resolve-dependency-issues-in-a-package-development/33512/3 "2020-01-18T14:27:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mateuszbaran](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mateuszbaran/32/221842_2.png) [@mateuszbaran](https://discourse.julialang.org/u/mateuszbaran)\
**Post date:** [January 20, 2020, 9:16am UTC](https://discourse.julialang.org/t/schematic-way-to-resolve-dependency-issues-in-a-package-development/33512/4 "2020-01-20T09:16:59Z")

</div>

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.