Unsatisfiable requirements when trying to release new version of QuantumControl package

Tooling Package Management
, ,
1

I’m having trouble parsing the following error message from https://github.com/JuliaRegistries/General/runs/5088377586?check_suite_focus=true

ERROR: Unsatisfiable requirements detected for package GRAPE [6b52fcaf]:
 GRAPE [6b52fcaf] log:
 ├─possible versions are: 0.0.1-0.0.2 or uninstalled
 ├─restricted by compatibility requirements with QuantumControl [8a270532] to versions: 0.0.2
 │ └─QuantumControl [8a270532] log:
 │   ├─possible versions are: 0.0.1-0.0.4 or uninstalled
 │   └─restricted to versions 0.0.4 by an explicit requirement, leaving only versions 0.0.4
 └─restricted by compatibility requirements with QuantumPropagators [7bf12567] to versions: uninstalled — no versions left
   └─QuantumPropagators [7bf12567] log:
     ├─possible versions are: 0.0.1-0.1.0 or uninstalled
     └─restricted by compatibility requirements with QuantumControl [8a270532] to versions: 0.1.0
       └─QuantumControl [8a270532] log: see above

This is from a failed attempt to release a new 0.0.4 verrsion of QuantumControl, see https://github.com/JuliaRegistries/General/pull/54068

A guide: How to handle "ERROR: Unsatisfiable requirements detected ..." has been quite helpful to parse the error message, but I’m still struggling.

First, the “possible versions”: are those solely determined by what’s in the General registry?

Second, I’m reading the above as follows:

  • We’re trying to install the GRAPE package
  • QuantumControl 0.0.4 restricts GRAPE to 0.0.2 (true!)
  • QuantumPropgators 0.1.0 restricts GRAPE to “uninstalled” (huh?)

For my general understanding: the “restricted by compatibility…” lines are independent in this output, right? This is not some kind of “accumulative” restriction?

Also, the indented trees, QuantumControl [8a270532] log, QuantumPropagators [7bf12567] log only tell me why QuantumControl and QuantumPropagators are being installed in a specific version, right? So mentally, I could shorten that to e.g. restricted by compatibility requirements with QuantumControl **0.0.4** to versions: 0.0.2 and forget about the subtree?

Now, the real question is why QuantumPropagators would restrict GRAPE. QuantumPropagators is being installed in version 0.1.0, so the relevant Project.toml is this one: https://github.com/JuliaQuantumControl/QuantumPropagators.jl/blob/v0.1.0/Project.toml

It does not contain a reference to GRAPE, neither directly nor indirectly (no package in the dependencies depends on anything that depends on GRAPE). So WTF?

The testing dependencies in https://github.com/JuliaQuantumControl/QuantumPropagators.jl/blob/v0.1.0/test/Project.toml should not influence this at all, right? (I thought there might be an indirect dependency there on GRAPE, but there is not, in fact. So even that wouldn’t explain the problem).

All of these packages are part of JuliaQuantumControl, and the packages in that org have the following dependencies on each other:

┌─────────────────────┐
│ QuantumPropagators  ◀────────────────────────┐
└──────────▲──────────┘                        │
           │                                   │
           │                                   │
┌──────────┴───────────┐            ┌──────────┴─────────┐
│  QuantumControlBase  ◀────────────┤   QuantumControl   │
└────▲─────────────▲───┘            └──────┬───┬─────────┘
     │             │                       │   │
     │             │                       │   │
┌────┴─────┐   ┌───┴───┐                   │   │
│  Krotov  │   │ GRAPE ◀───────────────────┘   │
└────▲─────┘   └───────┘                       │
     │                                         │
     │                                         │
     └─────────────────────────────────────────┘

where "────▶" means "depends on"

In addition, the testing of Krotov and GRAPE also depend on QuantumControl (which is why I thought the Project.toml might be the root of the problem)

1 Like
2

By giving the package manager some more information you can sometimes get better error messages. Here are the known hard requirements:

  • QuantumControl@0.0.4 (what the PR tries to install)
  • GRAPE@0.0.2 (required by QuantumControl@0.0.4)
  • QuantumControlBase@0.1 (required by QuantumControl@0.0.4)

If we feed this to Pkg:

$ pkg add GRAPE@0.0.2 QuantumControl@0.0.4 QuantumControlBase@0.1
   Resolving package versions...
ResolverError: Unsatisfiable requirements detected for package QuantumControlBase [f10a33bc]:
 QuantumControlBase [f10a33bc] log:
 ├─possible versions are: 0.0.1-0.1.0 or uninstalled
 ├─restricted to versions 0.1 by an explicit requirement, leaving only versions 0.1.0
 └─restricted by compatibility requirements with GRAPE [6b52fcaf] to versions: 0.0.1-0.0.3 — no versions left
   └─GRAPE [6b52fcaf] log:
     ├─possible versions are: 0.0.1-0.0.2 or uninstalled
     └─restricted to versions 0.0.2 by an explicit requirement, leaving only versions 0.0.2

we get a better error. Here we see that GRAPE@0.0.2 requires QuantumControlBase@0.0.1-0.0.3, but that’s an unsatisfiable requirement – we already required QuantumControlBase@0.1 as a hard requirement from the start!

The solution (at least a first step) is to release a version of GRAPE that supports QuantumControlBase@0.1.

4 Likes
3

Wow, that actually makes total sense! Both GRAPE and Krotov are in this situation, so I’ll try making a release for both of them later tonight, and then try QuantumControl again.

That’s actually what I was trying to do in the first place (release QuantumControl.jl 0.1.0 that pulls in the 0.1.0 of all the sub-packages). I might have to do the GRAPE and Krotov releases “blindly” since the test workflows won’t run until QuantumControl is updated)… which I why I was trying do to the QuantumControl.jl 0.0.4 as a temporary intermediate step.

The “circular” dependency of the tests is really what’s making this so complicated. I’ll have to think if I can untangle that. But anyway, I think you’re right: I can probably update GRAPE and Krotov and then QuantumControl, and that should work.

I’ll report back later tonight or tomorrow.

1 Like
4

It worked! After releasing everything in order, and re-running all pipelines a few times, everything’s now green across the board, and I think I understand how to avoid this kind of situation in the future.

Thanks again!