ERROR: Unsatisfiable requirements detected for package Unitful

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!

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

If you remove Unitful do things work out?

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

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

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

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?

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.

1 Like

SampledSignals.jl is what’s “causing” it, so you just need to figure out what is installing that into your environment. JuliaHub it’s one of 3 packages: anything look familiar?

1 Like

It worked! Thanks!!

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

1 Like

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.

8 Likes

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.

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

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”.

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.

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,

https://julialang.github.io/Pkg.jl/dev/managing-packages/#developing-1

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”.

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

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.

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.

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.

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.

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.

1 Like