Pkg.ResolveError "Unsatisfiable requirements detected": recovering an environment without a committed Manifest.toml
0 reputation · 09 Nov 2024, 14:14 UTC
0 reputation · 09 Nov 2024, 14:14 UTC
On Julia 1.10, running Pkg.update() on a project fails during resolution with Pkg.ResolveError: Unsatisfiable requirements detected. The resolver reports a conflict attributed to an indirect dependency rather than any package listed directly in Project.toml.
The Project.toml and Manifest.toml pair for this environment was never committed to version control, so there is no known-good snapshot to restore with Pkg.instantiate(). The documentation indicates the failed resolution leaves the existing manifest unchanged, so the environment should still be usable, but the goal is to reach an updated state, not merely stay on the old one.
The compat bounds in Project.toml are broad, and it is unclear which transitive dependency's requirements actually block the update. Hand-editing either TOML file is documented as unsupported.
Pkg.ResolveError, or is trial pinning with Pkg.pin() the intended diagnostic path?30775 reputation · 09 Nov 2024, 17:52 UTC
When Pkg.update() fails with a Pkg.ResolveError, the Julia package manager performs an atomic operation: it attempts to find a valid solution, and if it fails, it leaves the existing Manifest.toml untouched. Because you have no version control snapshot, your current on-disk Manifest.toml is your only recoverable baseline. To avoid losing this working state during diagnostics, manually back up the file before attempting further resolution changes.
There is no single command that outputs a "minimal set" of conflicting constraints. The intended diagnostic path is a combination of reading the resolver's error output and tracing dependency chains. Trial pinning is a workaround to force a resolution, but it is not the primary diagnostic tool.
Pkg.why("PackageName") (available in Julia 1.9+) to determine which of your direct dependencies are pulling in the problematic indirect package.Project.toml to a temporary folder, add the indirect package as a direct dependency, and run Pkg.resolve(). This often surfaces the specific compat entry causing the block.The resolver's attribution to an indirect dependency is generally accurate regarding where the contradiction surfaces, but it does not always identify the root cause. The blocker is often a strict compat bound in one of your direct dependencies or a limitation imposed by the Julia version itself. Treat the named indirect package as the symptom; the fix usually involves adjusting the compat bounds of the parent package.
Follow these steps to move toward an updated state while preserving your current environment:
Manifest.toml to Manifest.toml.bak.Pkg.Registry.update() to ensure you aren't fighting outdated registry data.Pkg.compat to widen the bounds of the implicated direct dependency if you have the authority to do so.Pkg.update(), try updating specific packages to see if the conflict is isolated to a single branch of the dependency tree.Missing Diagnostic: Does the resolver output indicate the conflict is with the stdlib or a specific Julia version bound? If so, the resolution may require a Julia version upgrade rather than package adjustments.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.