Open DaAwesomeP opened 1 year ago
I opted not to open a pull request because this should effectively be changed at the time of next release (should the change be accepted).
There is indeed no guarantee that a future maestral
version may be incompatible with maestral-qt
, though the "gui" extra in maestral does specify the "reverse" dependency, i.e., which GUI version is required:
[project.optional-dependencies]
gui = [
"maestral-qt>=1.7.1;sys_platform=='linux'",
"maestral-cocoa>=1.7.1;sys_platform=='darwin'",
]
Those versions should be enforced at runtime when running maestral gui
.
Pinning is indeed an alternative, maybe even a more elegant than runtime checks, but it does preclude the possibility allowing an older GUI version to work with a newer daemon.
I recently accidentally updated the
maestral
package via pip but forgot to update themaestral-qt
package. I was runningmaestral
v1.7.1 withmaestral-qt
v1.6.5. I assume there is no guarantee of compatibility in a scenario like this? Or maybe there is currently a compatibility guarantee but not between a futuremaestral
v2.x.x andmaestral-qt
v1.x.x?Currently this package depends on any greater or equal version of
maestral
, but setting it to the exact version should cause pip to show a warning updating one and not the other.https://github.com/samschott/maestral-qt/blob/9829be524d793581df8ebb9f14bda9b26946a5ea/setup.cfg#L31