samschott / maestral-qt

A Qt interface for the Maestral daemon
MIT License
10 stars 3 forks source link

Require exact maestral version #25

Open DaAwesomeP opened 1 year ago

DaAwesomeP commented 1 year ago

I recently accidentally updated the maestral package via pip but forgot to update the maestral-qt package. I was running maestral v1.7.1 with maestral-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 future maestral v2.x.x and maestral-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

DaAwesomeP commented 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).

samschott commented 1 year ago

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:

https://github.com/samschott/maestral/blob/eb47bd562e4a8345b13e59cba77ff8c1a0dec25f/pyproject.toml#L50-L54

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