Develop a manager for Modelica packages

[Martin Sjölund]

Backend:

• We need to be able to categorize packages (#5726)
  • The category should be different for different tags and branches
• We should probably use JSON or other text-based format
  • Need to store dependencies of packages
• Should we pre-compile BuildProjects?
• Should we find releases containing pre-compiled binaries?
• Should we check that the library parses properly before being included? Mark in some way that a library version is broken with suggestion for remedy? Maybe even automatically suggest a replacement...
• Should we look for conversion annotations and supply a list of compatible libraries that do not need conversion (and install the latest version not requiring conversion)?
• There are packages not on github as well

Frontend:

• Should we use JSON or sqlite? (Might be different from backend format) Should we download only a single file or the entire git history of changes?
• We need to be able to install package by latest (release), tag or branch
• Should we be able to install multiple versions of the same package at the same time?
• We need to handle packages with non-UTF8 encodings
• Single git repository contains multiple packages in many cases. Should we install all of them at the same time?
• Should we install packages by zip/tarball/git?
• Should the frontend work in the GUI?
• Should the frontend work on command-line?
• Should the frontend work using scripting commands?
• We need to store which packages are maintained by the frontend (as opposed to packages manually put in the path by a user), and which tag/branch they follow
• How should dependencies be handled?
  • Only install tagged versions automatically?
  • The registry might not need to know the versions of packages in branches and only store latest sha, only registering when installing a selected branch (but if it has version tags causing a conflict, this might not be detected until after trying to install in that case; unless we force branches to install under a different name)
  • If a package does not have any tagged release, should we look to see what version the default branch provides anyway?

We have local patches for MSL. Should we treat MSL differently from other libraries? (The patches are different for all git commits; we use mos-scripts to add annotations at certain places, which is more robust than plain-text diffs)
We could for example have our own local MSL copy with patches already applied.

[Martin Sjölund]

Fixed in ​https://github.com/OpenModelica/OpenModelica/pull/814 and many subsequent commits :)

To answer some of my own comments:

• JSON over sqlite
• Can install multiple versions of the same package
• Handles non-UTF8 encodings by ignoring problems now
• We install package by package
• We install by zip-file as provided by Github/Gitlab in most cases
• The GUI parts are not added yet
• There is no stand-alone command to install packages without mos-script
• The scripting API supports the package manager
• The installed packages are all in a specific location with JSON-files containing metadata. This does not store which branch/etc they follow since when upgrading we simply look at conversion script annotations to know what we can upgrade to.
• We install the best version automatically (branches are considered prereleases and have lower priority)

MSL is treated by having our own git repository for it, that already includes our patches.