Open-MSS / MSS

A QT application, a OGC web map server, a collaboration server to plan atmospheric research flights.
https://open-mss.github.io
Apache License 2.0
63 stars 87 forks source link

update the documentation for pixi (global) install mss #1922

Open ReimarBauer opened 1 year ago

ReimarBauer commented 1 year ago

The install documentation for users can have an alternative option use pixi. This is much simpler as our shell scripts.

pixi global install mss
✔ Installed package mss 8.2.0 py310hff52083_0 from conda-forge
  These apps are now globally available:
   -  .mss-post-link
   -  .mss-pre-unlink
   -  mscolab
   -  mss
   -  mssautoplot
   -  msui
   -  mswms
   -  mswms_demodata

https://prefix.dev/docs/pixi/cli

ReimarBauer commented 1 year ago

We have to find a solution for the other command line tools which we have when we are in an environment.

matrss commented 1 year ago

I think we should differentiate between an installation on the user side and on the server side here. E.g. database migrations are a thing that is only of concern on the server side, for example when hosting mscolab, right? I also did not encounter a need for keyring yet.

In the case of ncdump I'd argue that that is accessible to mss already if it is needed, but should not be exposed to a user installing with pixi global install: if we did that, then this ncdump version would come from the mss environment, with all its version constraints imposed on it. If the user instead explicitly pixi global installed it themselves, then they get an up-to-date version without all those limitations that do not necessarily apply outside of mss.

Having all these version constraints affect each other in a standard mamba environment even when the usage of the installed packages is not at all tightly coupled is one of the bigger downsides of mamba, imho.

On the server side I think pixi global install is the wrong approach anyway: compared to a regular pixi project it does not provide a proper lock file (AFAIK?) and makes multiple different versions side by side much harder or impossible (think develop/staging and production, for example). Instead, we could create a pixi project, install mss in that, get a lock file of this environment, update this environment in its entirety (recreate lock file) or just single dependencies (when pixi supports that) and have all this as a manageable single directory containing the lock file + state of the application (modulo database or whatever).

I guess the TL;DR is: I don't think we need to "export" binaries of other packages, if they are needed outside of mss they should be installed separately.

ReimarBauer commented 3 days ago

When we don't do a global install we just need a pixi shell to access all the mentioned commands.

e.g.

which ncdump
/home/reimar/pixidirs/mss/.pixi/envs/default/bin/ncdump

As I already told anaconda licensees how to use pixi we can add it to our docs.