# ERROR: Unsatisfiable requirements detected for package Unitful

**URL:** <https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699>\
**Category:** New to Julia\
**Tags:** pkg\
**Created:** [August 10, 2020, 5:01pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699 "2020-08-10T17:01:45Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![jtoledom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jtoledom/32/216799_2.png) [@jtoledom](https://discourse.julialang.org/u/jtoledom)\
**Post date:** [August 10, 2020, 5:01pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/1 "2020-08-10T17:01:45Z")

</div>

Hi. I’m getting this error when adding the NeuralPDE Pkg. I’m using Julia 1.5 (also tried on 1.0.5 and 1.4.2 and I get a similar log). I don’t know how to interpret it. Any help will be highly appreciated.

Don’t know if this is of any relevance, but when moving to Julia 1.5 I used my 1.4.2 Manifest.

Thank you!

```julia
ERROR: Unsatisfiable requirements detected for package Unitful [1986cc42]:
 Unitful [1986cc42] log:
 ├─possible versions are: [0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0, 0.17.0, 0.18.0, 1.0.0, 1.1.0, 1.2.0-1.2.1, 1.3.0] or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions [0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0, 0.17.0, 0.18.0, 1.0.0, 1.1.0, 1.2.0-1.2.1, 1.3.0]
 ├─restricted by compatibility requirements with SampledSignals [bd7594eb] to versions: [0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0, 0.17.0, 0.18.0]
 │ └─SampledSignals [bd7594eb] log:
 │ ├─possible versions are: [2.0.0, 2.1.0] or uninstalled
 │ └─restricted by compatibility requirements with LibSndFile [b13ce0c6] to versions: [2.0.0, 2.1.0]
 │ └─LibSndFile [b13ce0c6] log:
 │ ├─possible versions are: [2.0.0, 2.1.0, 2.2.0, 2.3.0] or uninstalled
 │ └─restricted to versions * by an explicit requirement, leaving only versions [2.0.0, 2.1.0, 2.2.0, 2.3.0]
 └─restricted by compatibility requirements with ModelingToolkit [961ee093] to versions: [1.1.0, 1.2.0-1.2.1, 1.3.0] — no versions left
   └─ModelingToolkit [961ee093] log:
     ├─possible versions are: [0.0.1-0.0.2, 0.1.0, 0.2.0, 0.4.0, 0.5.0, 0.6.0-0.6.1, 0.6.3-0.6.4, 0.7.0-0.7.2, 0.8.0, 0.9.0-0.9.1, 0.10.0, 1.0.0-1.0.3, 1.1.0-1.1.3, 1.2.0-1.2.10, 1.3.0-1.3.3, 1.4.0-1.4.3, 2.0.0, 3.0.0-3.0.2, 3.1.0-3.1.1, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0-3.6.4, 3.7.0-3.7.1, 3.8.0, 3.9.0, 3.10.0-3.10.2, 3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0] or uninstalled
     ├─restricted to versions * by an explicit requirement, leaving only versions [0.0.1-0.0.2, 0.1.0, 0.2.0, 0.4.0, 0.5.0, 0.6.0-0.6.1, 0.6.3-0.6.4, 0.7.0-0.7.2, 0.8.0, 0.9.0-0.9.1, 0.10.0, 1.0.0-1.0.3, 1.1.0-1.1.3, 1.2.0-1.2.10, 1.3.0-1.3.3, 1.4.0-1.4.3, 2.0.0, 3.0.0-3.0.2, 3.1.0-3.1.1, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0-3.6.4, 3.7.0-3.7.1, 3.8.0, 3.9.0, 3.10.0-3.10.2, 3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0]
     ├─restricted by compatibility requirements with DataDrivenDiffEq [2445eb08] to versions: [0.9.0-0.9.1, 0.10.0, 1.0.0-1.0.3, 1.1.0-1.1.3, 1.2.0-1.2.10, 1.3.0-1.3.3, 1.4.0-1.4.3, 3.0.0-3.0.2, 3.1.0-3.1.1, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0-3.6.4, 3.7.0-3.7.1, 3.8.0, 3.9.0, 3.10.0-3.10.2, 3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0]
     │ └─DataDrivenDiffEq [2445eb08] log:
     │ ├─possible versions are: [0.1.0-0.1.4, 0.2.0, 0.3.0-0.3.2] or uninstalled
     │ ├─restricted to versions * by an explicit requirement, leaving only versions [0.1.0-0.1.4, 0.2.0, 0.3.0-0.3.2]
     │ └─restricted by compatibility requirements with ModelingToolkit [961ee093] to versions: [0.2.0, 0.3.0-0.3.2] or uninstalled, leaving only versions: [0.2.0, 0.3.0-0.3.2]
     │ └─ModelingToolkit [961ee093] log: see above
     └─restricted by compatibility requirements with NeuralPDE [315f7962] to versions: [3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0]
       └─NeuralPDE [315f7962] log:
         ├─possible versions are: 2.0.0 or uninstalled
         └─restricted to versions * by an explicit requirement, leaving only versions 2.0.0

```

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 10, 2020, 9:13pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/2 "2020-08-10T21:13:23Z")

</div>

If you remove Unitful do things work out?

---

<div class="post-metadata">

**Author:** ![jtoledom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jtoledom/32/216799_2.png) [@jtoledom](https://discourse.julialang.org/u/jtoledom)\
**Post date:** [August 10, 2020, 9:34pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/3 "2020-08-10T21:34:35Z")

</div>

So I did `Pkg.rm("Unitful")` and then `] gc` and tried again `] add NeuralPDE` but it seems I’m getting the exact same error:

```julia
ERROR: Unsatisfiable requirements detected for package Unitful [1986cc42]:
 Unitful [1986cc42] log:
 ├─possible versions are: [0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0, 0.17.0, 0.18.0, 1.0.0, 1.1.0, 1.2.0-1.2.1, 1.3.0] or uninstalled
 ├─restricted by compatibility requirements with SampledSignals [bd7594eb] to versions: [0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.0, 0.17.0, 0.18.0]
 │ └─SampledSignals [bd7594eb] log:
 │ ├─possible versions are: [2.0.0, 2.1.0] or uninstalled
 │ └─restricted by compatibility requirements with LibSndFile [b13ce0c6] to versions: [2.0.0, 2.1.0]
 │ └─LibSndFile [b13ce0c6] log:
 │ ├─possible versions are: [2.0.0, 2.1.0, 2.2.0, 2.3.0] or uninstalled
 │ └─restricted to versions * by an explicit requirement, leaving only versions [2.0.0, 2.1.0, 2.2.0, 2.3.0]
 └─restricted by compatibility requirements with ModelingToolkit [961ee093] to versions: [1.1.0, 1.2.0-1.2.1, 1.3.0] — no versions left
   └─ModelingToolkit [961ee093] log:
     ├─possible versions are: [0.0.1-0.0.2, 0.1.0, 0.2.0, 0.4.0, 0.5.0, 0.6.0-0.6.1, 0.6.3-0.6.4, 0.7.0-0.7.2, 0.8.0, 0.9.0-0.9.1, 0.10.0, 1.0.0-1.0.3, 1.1.0-1.1.3, 1.2.0-1.2.10, 1.3.0-1.3.3, 1.4.0-1.4.3, 2.0.0, 3.0.0-3.0.2, 3.1.0-3.1.1, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0-3.6.4, 3.7.0-3.7.1, 3.8.0, 3.9.0, 3.10.0-3.10.2, 3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0] or uninstalled
     ├─restricted to versions * by an explicit requirement, leaving only versions [0.0.1-0.0.2, 0.1.0, 0.2.0, 0.4.0, 0.5.0, 0.6.0-0.6.1, 0.6.3-0.6.4, 0.7.0-0.7.2, 0.8.0, 0.9.0-0.9.1, 0.10.0, 1.0.0-1.0.3, 1.1.0-1.1.3, 1.2.0-1.2.10, 1.3.0-1.3.3, 1.4.0-1.4.3, 2.0.0, 3.0.0-3.0.2, 3.1.0-3.1.1, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0-3.6.4, 3.7.0-3.7.1, 3.8.0, 3.9.0, 3.10.0-3.10.2, 3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0]
     ├─restricted by compatibility requirements with DataDrivenDiffEq [2445eb08] to versions: [0.9.0-0.9.1, 0.10.0, 1.0.0-1.0.3, 1.1.0-1.1.3, 1.2.0-1.2.10, 1.3.0-1.3.3, 1.4.0-1.4.3, 3.0.0-3.0.2, 3.1.0-3.1.1, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0-3.6.4, 3.7.0-3.7.1, 3.8.0, 3.9.0, 3.10.0-3.10.2, 3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0]
     │ └─DataDrivenDiffEq [2445eb08] log:
     │ ├─possible versions are: [0.1.0-0.1.4, 0.2.0, 0.3.0-0.3.2] or uninstalled
     │ ├─restricted to versions * by an explicit requirement, leaving only versions [0.1.0-0.1.4, 0.2.0, 0.3.0-0.3.2]
     │ └─restricted by compatibility requirements with ModelingToolkit [961ee093] to versions: [0.2.0, 0.3.0-0.3.2] or uninstalled, leaving only versions: [0.2.0, 0.3.0-0.3.2]
     │ └─ModelingToolkit [961ee093] log: see above
     └─restricted by compatibility requirements with NeuralPDE [315f7962] to versions: [3.11.0-3.11.1, 3.12.0-3.12.2, 3.13.0, 3.14.0-3.14.2, 3.15.0]
       └─NeuralPDE [315f7962] log:
         ├─possible versions are: 2.0.0 or uninstalled
         └─restricted to versions * by an explicit requirement, leaving only versions 2.0.0

```

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 10, 2020, 9:38pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/4 "2020-08-10T21:38:08Z")

</div>

Oh, looks like it could be SampledSignals.jl that doesn’t allow Unitful v1.0? Try dropping SampledSignals and see if that works.

---

<div class="post-metadata">

**Author:** ![jtoledom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jtoledom/32/216799_2.png) [@jtoledom](https://discourse.julialang.org/u/jtoledom)\
**Post date:** [August 10, 2020, 9:46pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/5 "2020-08-10T21:46:57Z")

</div>

No, it didn’t work.

I didn’t have SampledSignals.jl added. So I added it (just in case) and went at it again, got the same error. I then removed SampledSignals.jl and went at it again (just in case) and same error.

Should I just try a fresh install of all Pkg’s and call it a day?

---

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [August 10, 2020, 10:57pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/6 "2020-08-10T22:57:50Z")

</div>

It’d be easier for people to help you troubleshoot if you could upload and link to a copy of your Project.toml and Manifest.toml.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 10, 2020, 11:33pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/7 "2020-08-10T23:33:23Z")

</div>

> [@jtoledom](#):
>
> I didn’t have SampledSignals.jl added. So I added it (just in case) and went at it again, got the same error. I then removed SampledSignals.jl and went at it again (just in case) and same error.

SampledSignals.jl is what’s “causing” it, so you just need to figure out what is installing that into your environment. [JuliaHub](https://juliahub.com/ui/Packages/SampledSignals/lW2gH/2.1.0?t=2) it’s one of 3 packages: anything look familiar?

---

<div class="post-metadata">

**Author:** ![jtoledom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jtoledom/32/216799_2.png) [@jtoledom](https://discourse.julialang.org/u/jtoledom)\
**Post date:** [August 10, 2020, 11:47pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/8 "2020-08-10T23:47:12Z")

</div>

It worked! Thanks!!

It was **LibSndFile** … I think I got it from MusicProcessing…

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 11, 2020, 9:49pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/9 "2020-08-11T21:49:58Z")

</div>

Incidentally, this looks like a good advert for using Julia’s environments when writing code - when installing loads of packages into your default environment you very quickly run into these kinds of issues.

If you had had a separate environment for whatever code required MusicProcessing and the code for which you tried to use NeuralPDE, the could have happily coexisted on your machine.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [August 12, 2020, 3:44am UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/10 "2020-08-12T03:44:04Z")

</div>

Even though I use julia environments for working on different projects, still think that it would be useful in some cases to have something like `]add --no-deps SomePackage@version`: ignore all dependency restrictions put by this package and just install the specified version. Basically every other package manager I know of has a similar flag or option.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 12, 2020, 8:16am UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/11 "2020-08-12T08:16:58Z")

</div>

> [@aplavin](#):
>
> ignore all dependency restrictions put by this package and just install the specified version

Keep in mind that with SemVer-conforming packages, this would almost guarantee breaking stuff when the result is different from a plain vanilla `add` etc. Cf

> <https://github.com/JuliaLang/Pkg.jl/pull/1607>
>
> Since this change is so small, I might as well probe what people think about thi…s.
> 
> This adds an option that just turns off all compat (except the compat in your project) and gives you the latest versions of everything.
> 
> \`\`\`jl
> julia\> Pkg.update()
> Updating \`~/.julia/environments/v1.3/Project.toml\`
> \[no changes\]
> Updating \`~/.julia/environments/v1.3/Manifest.toml\`
> \[no changes\]
> 
> julia\> Pkg.update(; ignore\_compat=true)
> Updating \`~/.julia/environments/v1.3/Project.toml\`
> \[no changes\]
> Updating \`~/.julia/environments/v1.3/Manifest.toml\`
> \[68821587\] ↑ Arpack\_jll v3.5.0+2 ⇒ v3.7.0+0
> \[a81c6b42\] ↑ Compose v0.7.3 ⇒ v0.8.0
> \[31c24e10\] ↑ Distributions v0.21.12 ⇒ v0.22.0
> \[ae029012\] ↑ Requires v0.5.2 ⇒ v1.0.0
> \`\`\`
> 
> No docs yet because that will be the majority of the work for this PR and I want to see some opinions first.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [August 12, 2020, 11:46am UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/12 "2020-08-12T11:46:56Z")

</div>

> [@Tamas\_Papp](#):
>
> this would almost guarantee breaking stuff when the result is different from a plain vanilla `add`

This is really often not the case. A new SemVer-incompatible version of a package doesn’t suddenly break _everything_: typically only some functions/parameter combinations stop working or behave differently.

I think an option to ignore dependencies will become more and more useful over time as the number of abandoned-but-still-working-fine packages grows. Even for actively developed packages their authors neither update compats immediately nor synchronize these updates with other packages. It is way more useful to say `add --ignore-deps` and have a probably-working setup with the latest (or even any) versions immediately - compared to waiting and hoping that package authors update the compats soon. In the latter case one definitely has no working setup with the needed package versions - strictly worse than “probably/possibly working”.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 12, 2020, 11:57am UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/13 "2020-08-12T11:57:06Z")

</div>

> [@aplavin](#):
>
> A new SemVer-incompatible version of a package doesn’t suddenly break _everything_ : typically only some functions/parameter combinations stop working or behave differently.

Please kindly reread what I wrote above: there is no claim that it would break _everything_.

Nevertheless, if package APIs _do_ follow SemVer, and compat bounds which would otherwise prevent upgrading are ignored, then there is a high chance that something _will_ break. Given that a typical Julia package has at least 20–30 entries in the manifest, this is a possibility with a nontrivial probability.

> [@aplavin](#):
>
> Even for actively developed packages their authors neither update compats immediately nor synchronize these updates with other packages. It is way more useful to say `add --ignore-deps` and have a probably-working setup with the latest (or even any) versions immediately - compared to waiting and hoping that package authors update the compats soon. In the latter case one definitely has no working setup with the needed package versions - strictly worse than “probably/possibly working”.

I am not sure if you are aware of this, but you can fork or `dev` a package, make the required change, and use it while you are waiting for the update from the package devs. Ideally you can also submit this as PR at a low marginal cost and thus contribute to a faster change for everyone. See, among other things,

> **[3. Managing Packages · Pkg.jl](https://pkgdocs.julialang.org/dev/managing-packages/)**
>
> Documentation for Pkg.jl.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [August 12, 2020, 12:10pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/14 "2020-08-12T12:10:55Z")

</div>

> [@Tamas\_Papp](#):
>
> Nevertheless, if package APIs _do_ follow SemVer, and compat bounds which would otherwise prevent upgrading are ignored, then there is a high chance that something _will_ break. Given that a typical Julia package has at least 20–30 entries in the manifest, this is a possibility with a nontrivial probability.

Oh, I guess I didn’t explain it well. I don’t mean there should be a single option to ignore all dependencies of all packages! Maybe it should be called `--force` in the sense that it forces installing a specific version of a specific package, even if the solver is not happy with it. It would be fine if further Pkg commands give warnings everytime to remind that the environment is not “clean”.

> [@Tamas\_Papp](#):
>
> but you can fork or `dev` a package, make the required change, and use it while you are waiting for the update from the package devs

This is definitely a possibility for developers - but it’s just easier for users to give a reasonable option to `add`. Also not clear how to deal with abandoned packages in this way: manually `dev` & modify their compats every time you need to install them? “fork” every such package, publish to some online git hosting, and add by `git` URL? if there are several abandoned packages that depend on one another - …?

> [@Tamas\_Papp](#):
>
> Ideally you can also submit this as PR at a low marginal cost and thus contribute to a faster change for everyone.

If the authors are available and willing to accept the PR - maybe. But as you say, something likely breaks in such updates, even if the breakage doesn’t affect my particular usecase.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 12, 2020, 12:18pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/15 "2020-08-12T12:18:02Z")

</div>

> [@aplavin](#):
>
> This is definitely a possibility for developers - but it’s just easier for users

TBH, I find the developers/users distinction meaningless in Julia. If you write code, no matter how trivial, you are a “developer” and a “user” at the same time.

That said, if you consider less experienced programmers “users”, then unleashing a tool on them that potentially (and possibly silently) breaks stuff is the wrong solution as they are a group less equipped to deal with breakages.

> [@aplavin](#):
>
> if there are several abandoned packages that depend on one another - …?

You can either

1. dev them all,
2. or even better, offer to step in and take over maintenance.

But there is no silver bullet here. Abandonned software frequently requires some form of dusting off to work.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [August 12, 2020, 12:28pm UTC](https://discourse.julialang.org/t/error-unsatisfiable-requirements-detected-for-package-unitful/44699/16 "2020-08-12T12:28:30Z")

</div>

> [@Tamas\_Papp](#):
>
> But there is no silver bullet here. Abandonned software frequently requires some form of dusting off to work.

There is no silver bullet indeed, but an option to ignore compats is at least a partial solution that would work in some such cases - and “some” is better than “none”. An “abandoned package” may be something relatively small that uses e.g. `StatsBase.median` - but compat bounds won’t let you install a newer version of `StatsBase`.

> [@Tamas\_Papp](#):
>
> 1. or even better, offer to step in and take over maintenance.

This is way (WAY!) more involved than just saying “install that particular version”. It requires lots of stuff - familiarity with git, a github account, knowledge of julia general registry practices (i.e., how to replace a git url for a registered package), and also one should probably ensure that the compat update doesn’t break _anything_ - not only that original usecase.

Anyway, I see (not the first time) that there is strong opposition to such an option here (that I do not understand), and don’t want to argue much about this. Just wanted to say it would definitely be useful in some cases.