Add an MSS updater

[Marilyth]

fixes #899

• 1. Check if version is a lower number than conda search mss
• 2. Check if a simple mamba/conda install mss={newest} python is sufficient

I have decided against the functionality to create and replace the current environment. It is an absolute nightmare especially on Windows and its permission system. Random crashes can ruin the environment etc.

Also it seems coverage does not capture QThreads, which is a bummer since the majority of the updater is running in the background.

[ReimarBauer]

on windows we used

mamba install mss python=3.9 

this was used by me recently also on linux.

probably we could verify first which python version is available and not request a minor one.

[Marilyth]

Your command works only if there is no mss preinstalled I think. Otherwise mamba will keep the old mss version and be happy with it.
This worked for me on all my cases, be it a fresh environment or as a mss update

mamba install mss={version} python

where {version} is the latest one. Is there a reason to specify 3.9 instead of just telling mamba to match it to the newest mss @ReimarBauer ?
I have once managed to completely destroy my environment in which case that command didn't work. Which is why the environment replacement exists, but it is very dangerous if interrupted.

[ReimarBauer]

Your command works only if there is no mss preinstalled I think. Otherwise mamba will keep the old mss version and be happy with it.
This worked for me on all my cases, be it a fresh environment or as a mss update

mamba install mss={version} python

where {version} is the latest one. Is there a reason to specify 3.9 instead of just telling mamba to match it to the newest mss @ReimarBauer ?
I have once managed to completely destroy my environment in which case that command didn't work. Which is why the environment replacement exists, but it is very dangerous if interrupted.

The previous python=3.9 was some time ago a solution for a few windows installations.

[ReimarBauer]

the replacement of an existing env is something which should be explained to the user. And I'm still not sure if we should do this automated.

I'm also not sure if this scales, when a user has own plugins, libs additional installed in an mssenv.

An other option is to guide the user through these steps for a backupped new installation. So it is half automated and we could also verify that it probably will be successful.

[Marilyth]

the replacement of an existing env is something which should be explained to the user. And I'm still not sure if we should do this automated.

I'm also not sure if this scales, when a user has own plugins, libs additional installed in an mssenv.

An other option is to guide the user through these steps for a backupped new installation. So it is half automated and we could also verify that it probably will be successful.

I fully agree. I pursued the ability to create and replace the environment in case an update does not work, but I had to give up.
It did work, sometimes, sometimes not. Random segfaults occured, crashes to the updater, permission issues on Windows, hacks for going out of the current environment. Ugh. This is not worth it.
In case it is ever considered again, the commits here document how I did it.

[ReimarBauer]

@Marilyth I do later a deeper review. I've seen already that it is centric to the UI user which is a good choice.

I would also like to have a command line feature, at least for the servers. That must not do everything like the gui but it should log or output on a command option that the version is outdated. If that is too much now we can postpone that.

[Marilyth]

Sure, I will detach the functions from the UI and bring the updater to the servers also.

[ReimarBauer]

played a little with it, with some fake versions. Works pretty well :)
unfortunately have the current versions not that feature ;)

[ReimarBauer]

very well done