Metadata-Version: 2.4
Name: seamm-manager
Version: 2026.10.6
Summary: The manager for SEAMM (Simulation Environment for Atomistic and Molecular Simulations): installs, updates and configures SEAMM in a uv-managed environment.
Home-page: https://github.com/molssi-seamm/seamm_manager
Author: Paul Saxe
Author-email: psaxe@molssi.org
License: GNU Lesser General Public License v3+
Keywords: SEAMM,plug-in,flowchart,installer,updater
Platform: Linux
Platform: Mac OS-X
Platform: Unix
Platform: Windows
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Science/Research
Classifier: Topic :: Scientific/Engineering :: Chemistry
Classifier: Topic :: Scientific/Engineering :: Physics
Classifier: License :: OSI Approved :: GNU Lesser General Public License v3 or later (LGPLv3+)
Classifier: Natural Language :: English
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Programming Language :: Python :: 3.12
Requires-Python: >=3.12
Description-Content-Type: text/x-rst
License-File: LICENSE
License-File: AUTHORS.rst
Requires-Dist: packaging
Requires-Dist: platformdirs
Requires-Dist: psutil
Requires-Dist: pmw
Requires-Dist: pyyaml
Requires-Dist: requests
Requires-Dist: seamm-util
Requires-Dist: seamm-widgets
Requires-Dist: tabulate
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: home-page
Dynamic: keywords
Dynamic: license
Dynamic: license-file
Dynamic: platform
Dynamic: requires-dist
Dynamic: requires-python
Dynamic: summary

=============
SEAMM Manager
=============

| |pull| |CI| |docs| |coverage| |lgtm| |PyUp|
| |Release| |PyPi|

Installs, updates and configures SEAMM (the Simulation Environment for Atomistic and
Molecular Simulations) in a uv-managed Python environment.

* Free software: GNU Lesser General Public License v3+
* Documentation: https://molssi-seamm.github.io/seamm_manager/index.html

.. |pull| image:: https://img.shields.io/github/issues-pr-raw/molssi-seamm/seamm_manager
   :target: https://github.com/molssi-seamm/seamm_manager/pulls
   :alt: GitHub pull requests

.. |CI| image:: https://github.com/molssi-seamm/seamm_manager/workflows/CI/badge.svg
   :target: https://github.com/molssi-seamm/seamm_manager/actions?query=workflow%3ACI
   :alt: CI status

.. |docs| image:: https://github.com/molssi-seamm/seamm_manager/workflows/Documentation/badge.svg
   :target: https://github.com/molssi-seamm/seamm_manager/actions?query=workflow%3ADocumentation
   :alt: Documentation Status

.. |coverage| image:: https://codecov.io/gh/molssi-seamm/seamm_manager/branch/master/graph/badge.svg
   :target: https://codecov.io/gh/molssi-seamm/seamm_manager
   :alt: Code coverage

.. |lgtm| image:: https://img.shields.io/lgtm/grade/python/g/molssi-seamm/seamm_manager.svg?logo=lgtm&logoWidth=18
   :target: https://lgtm.com/projects/g/molssi-seamm/seamm_manager/context:python
   :alt: Code Quality

.. |PyUp| image:: https://pyup.io/repos/github/molssi-seamm/seamm_manager/shield.svg
   :target: https://pyup.io/repos/github/molssi-seamm/seamm_manager/
   :alt: Updates for requirements

.. |Release| image:: https://github.com/molssi-seamm/seamm_manager/workflows/Release/badge.svg
   :target: https://github.com/molssi-seamm/seamm_manager/actions?query=workflow%3ARelease
   :alt: CI status for releases

.. |PyPi| image:: https://img.shields.io/pypi/v/seamm_manager.svg
   :target: https://pypi.python.org/pypi/seamm_manager
   :alt: Release version

Features
--------

* **One environment, all from PyPI.** SEAMM and every plug-in are installed into a
  Python virtual environment under the SEAMM root (``~/SEAMM/venv``) with `uv`_,
  constrained to a published lock file, so every installation gets the same
  known-good set of versions and installs in seconds.
* **The interpreter comes with it.** ``uv`` installs Python (with Tk for the
  graphical editor); no conda, no system Python needed for SEAMM itself.
* **Conda only for the codes.** External programs (MOPAC, Psi4, DFTB+, LAMMPS, ...)
  are installed by their plug-ins into their own conda environments, exactly as
  before; conda is only needed if you install one of those plug-ins.
* Services (the JobServer and the web interface), desktop apps, and the datastore are
  set up and kept current by the same tool.

Getting started
---------------

.. code-block:: bash

    curl -LsSf https://astral.sh/uv/install.sh | sh    # once, if you do not have uv
    uv tool install seamm-manager
    seamm-manager install --all

That creates ``~/SEAMM``, the environment inside it, and installs SEAMM with all the
MolSSI plug-ins. ``seamm-manager update --all`` keeps everything current; without any
arguments ``seamm-manager`` opens a graphical installer.

Coming from seamm-installer
---------------------------

``seamm-manager`` replaces ``seamm-installer``, which managed a conda environment.
Existing conda-based installations keep working but no longer receive updates. To
move: run the three lines above, then ``seamm-manager services create`` and
``seamm-manager apps create`` to point the JobServer, web interface and desktop apps
at the new environment. Your jobs, configuration files and the codes' own conda
environments are untouched. Remove the old conda environment when you are happy.

.. _uv: https://docs.astral.sh/uv/

Acknowledgements
----------------

This package is based on ``seamm-installer``, and was developed by the Molecular
Sciences Software Institute (MolSSI_), which receives funding from the `National
Science Foundation`_ under awards OAC-1547580 and CHE-2136142.

.. _MolSSI: https://www.molssi.org
.. _`National Science Foundation`: https://www.nsf.gov


=======
History
=======
2026.10.6 -- The format-2.0 flowchart scan runs once
    * ``update`` scanned every job's flowchart for the old format 2.0 on every run,
      which on a cluster's network file system with tens of thousands of jobs took
      about 15 minutes. Once a scan (or ``flowcharts migrate``) finds nothing old,
      that is recorded in ``<root>/installation.ini`` (``[flowcharts] format = 3.0``)
      and later updates skip the scan; ``flowcharts status`` always scans and
      refreshes the record.
2026.10.5.1 -- PyTorch chosen for the machine; hand-built environments recognised
    * A plug-in whose code needs PyTorch (``torch_managed`` in its installer:
      xnn-step first) no longer takes whatever torch PyPI serves. The installer
      reads the NVIDIA driver's CUDA ceiling from ``nvidia-smi``, installs torch
      from the matching PyTorch index (``seamm_manager.torch_support``), puts the
      rest of the environment file's pip part on that index too, leaves a torch
      that works alone, never replaces one that does not without ``--torch-tag``
      (it may have been built on purpose), and checks afterwards that torch sees
      the GPU and the code imports. A machine with no driver -- a cluster's login
      node -- is asked to decide: ``torch-build = <tag>`` in the plug-in's .ini or
      ``--torch-tag`` (#31).
    * Whether a conda environment is SEAMM's is now read from conda's own history
      (created ``--file seamm-<step>.yml``), not only from the records SEAMM
      leaves when it applies a file: an environment SEAMM once updated by mistake
      has the records but is not SEAMM's.
2026.10.5 -- Stopped services stay stopped; hand-built code environments left alone
    * A service stopped on purpose stays stopped through an environment change or an
      update, which restart only the services that were running (#26).
    * ``environment recreate --latest`` takes each package's newest release on PyPI,
      not the package list's, which lags a release by up to a day (#27).
    * A plug-in's installer leaves alone a conda environment named in its .ini file
      that SEAMM did not make, such as a hand-built MLFF environment, instead of
      applying SEAMM's environment file to it (#28). An environment SEAMM made before
      it began marking them, under a name of the user's choosing, is now treated as
      the user's too.
    * ``update`` no longer runs the installer of a package it has refused as not a
      SEAMM package (#29).
    * ``install`` writes ``<root>/taskserver.ini`` -- the TaskServer's capacity, the
      physical cores and half the memory -- if it is missing.
2026.10.2.3 -- Bugfix: a refused switch no longer changes the current environment
    * After building a new version of the environment, the manager made sure that
      version held the manager's own release. It did so against whatever environment was
      current, so when the switch to the new version was refused (processes started
      through ``<root>/venv`` still running) it changed the environment in use, which the
      versioned environments exist to prevent. The manager's release is now put into the
      new version as part of the build, and the current environment is never touched.
    * Internal: 2026.10.2.2 was not published; one of its tests passed only on a
      development build and failed on the release. The test is fixed.

2026.10.2.1 -- Updates build a new environment rather than changing the current one
    * ``<root>/venv`` is now a link to the current version of the environment, kept in
      ``<root>/venvs/<date and time>``. ``update`` and ``install`` build the next version
      from a copy of the current one plus the change, switch the link, and restart the
      services from it, so a job that is running never sees a half-updated environment.
      The first such update moves an existing ``venv`` into place itself, safely while
      jobs run. ``--in-place`` keeps the old behaviour.
    * New ``environment versions``, ``switch``, ``rollback`` and ``prune`` commands;
      ``environment recreate`` now builds a fresh version and switches to it instead of
      deleting the environment first. A switch is refused, and the new version kept
      ready, while a process started through the link is still running (``--force``
      overrides).
    * New ``compare`` command: runs a flowchart in two environments -- two versions, or
      two installations -- and compares every file the runs produce, numbers within a
      tolerance and timestamps ignored. Use it to check a new version before switching.
    * The development packages of a development installation are updated in the new
      version with everything else, not in the current environment.

2026.10.2 -- Documentation: the upgrade guide for flowchart format 3.0
    * The installation page's section on converting the flowcharts to format 3.0 now
      points to the step-by-step guide in the main SEAMM documentation, *Upgrading to
      flowchart format 3.0*, which also covers the messages you may see, undoing the
      conversion and converting your own flowcharts.

2026.10.1.1 -- Bugfix: update now updates the web interface too
    * The web interface lives in its own environment (``venv-webui``), which ``update``
      never touched: an installation kept its old web interface, and the old datastore
      inside it, until it was updated by hand. ``update --all`` (and ``update
      seamm-webui``) now updates it to the newest release on PyPI, and restarts its
      service when anything in it changed. Found updating an installation to SEAMM
      2026.10.1, whose web interface could not otherwise read flowchart format 3.0.

2026.10.1 -- Convert flowcharts to format 3.0; rebuild the jobs database
    * New ``seamm-manager flowcharts migrate`` converts an installation's job
      flowcharts and its jobs database to SEAMM's new flowchart format 3.0 in one step:
      a dry run and its summary, a confirmation, then -- with the JobServer and web
      interface stopped -- the conversion, which backs up the database and keeps each
      original flowchart beside the new one. ``flowcharts status`` says how many are
      still in format 2.0, and ``update`` ends with a short notice when there are some.
    * New ``seamm-manager datastore rebuild`` rebuilds the jobs database from the job
      directories, keeping the accounts and job owners and the old database as a dated
      backup. A missing jobs database is now built from the job directories rather than
      created empty.
    * Paths are found correctly when SEAMM's packages are installed for development
      (editable).
    * Documented in Usage and Installation.

2026.9.29.2 -- Bugfix: update no longer reinstalls the running manager needlessly
    * ``update --all`` reinstalled the manager's own uv tool every time, even when it
      was already the newest release. On a network filesystem, as on a cluster, the
      running manager's open files can stop the old tool being removed, leaving it
      half deleted: the update then failed part way ("No module named
      'seamm_manager.policy'", and every package "could not reach PyPI"), and the
      manager no longer started. It is now reinstalled only when PyPI has a newer
      release.
    * If updating the manager fails, uv's error is shown, with the command to
      reinstall it.

2026.9.29.1 -- Bugfix: works with a cluster's central conda and Python
    * The codes' conda environments were always looked for, and made, in the conda
      installation's own ``envs`` directory. With a centrally provided conda, as on
      many clusters, that directory is read-only and the environments are elsewhere
      (``envs_dirs`` in ``~/.condarc``), so no environment could be found, updated or
      created. Environments are now found wherever conda has them, and new ones go in
      the first writable directory of ``envs_dirs``, as ``conda create -n`` would put
      them.
    * Installing no longer tries to recreate a code's conda environment that already
      exists; it uses it, and ``update`` brings it up to date.
    * The environment ``<root>/venv`` and the manager itself always use a Python
      installed by uv. When a conda environment was active -- as the central conda's
      base often is on a cluster -- uv used its Python instead, and the environment
      would break whenever that installation changed.

2026.9.29 -- Licensed codes get their configuration file on install
    * Installing the plug-in for a code you install yourself -- ORCA, Gaussian, VASP,
      FHI-aims -- now writes the plug-in's commented template, e.g. ``~/SEAMM/vasp.ini``,
      and says to edit it to give the code's location. Before, it only said to give the
      location in a file that did not exist. An existing file is never changed.
    * ``update`` no longer prints "Unable to update the executables because they were
      not installed using Conda" for these codes.

2026.9.28.1 -- Bugfix: updates respect every installed package's requirements
    * ``update --latest`` and ``--no-constraints`` resolved only the packages being
      updated and their dependencies, ignoring what the other installed packages
      require: updating seamm-thermochemistry moved pint to 0.26.1, breaking mendeleev,
      which needs ``pint<0.25``. Updates without the lock now resolve the whole
      installation at once -- the packages being updated, their dependencies and the
      requirements of everything else installed -- so dependencies are still brought
      up to date as far as every package allows, and if no set of versions satisfies
      them all the update stops with uv's explanation and changes nothing. With the
      lock (the default) everything is brought to the tested set, as before.
    * After installing or updating, the manager checks the environment and warns about
      any installed package whose requirements are not met.

2026.9.28 -- Bugfixes: the right installation, a sturdier datastore, quicker updates
    * The manager run from an installation's own environment -- such as
      ``~/SEAMM_DEV/venv/bin/seamm-manager``, or the app ``SEAMM-Manager (SEAMM_DEV)``
      -- worked on ``~/SEAMM``, showing production's services and shortcuts. It now
      works on the installation it runs from (``--root``, ``--development`` and
      ``$SEAMM_ROOT`` still take precedence), and treats ``~/SEAMM_DEV`` as the
      development installation.
    * ``update --all`` no longer re-solves every code's conda environment each time:
      a plug-in's environment file is applied again only if it changed, or after a
      week. ``update --refresh-codes`` applies them all now.
    * A jobs database that was never put under version control (as older development
      databases were) is now recognised and brought up to date instead of failing
      part-way; a new database is marked with its version when created; and an empty
      ``seamm.db`` (left by a JobServer started before the datastore was installed) or
      one without user accounts is set up properly instead of being taken as ready.
    * Updating the database while the JobServer ran would have crashed, and never
      stopped the JobServer first: it looked for the services under the wrong name.
    * When Zenodo cannot be reached, the manager uses the package list and lock it
      saved last time, with a one-line note, instead of printing a traceback.
    * On macOS, an editor's backup of a service file (``...plist~``) no longer shows up
      as a service.
    * Documentation: running several installations side by side, and trying a new
      release beside production.

2026.9.27.6 -- A trial installation cannot change production's codes
    * Each installation now has a code-environment policy for the external codes'
      conda environments, kept in ``<root>/installation.ini``. ``own`` (always the case
      for ``~/SEAMM``) creates and updates them as before. ``shared``, the default for
      any other installation, uses ``~/SEAMM``'s: installing a plug-in copies its
      ``<code>.ini`` from ``~/SEAMM``, and installing, updating or uninstalling never
      touches a conda environment, only reports. ``prefixed`` gives the installation its
      own copies named ``seamm-<name>-<code>``. ``install --code-environments`` chooses
      it and ``environment show`` shows it.
    * Before, installing plug-ins in a second installation recreated the shared
      environments, which is how a test on 2026-09-27 replaced the codes' environments
      on one machine.
    * The policy is applied by the seamm-manager in the installation's own
      environment. If that copy is too old to know about it, the manager now skips the
      plug-ins' install, update and uninstall steps in a non-default installation
      instead of letting them run.

2026.9.27.5 -- Several installations side by side; update --latest fixed
    * The services, desktop apps and macOS service bundles of an installation other
      than ``~/SEAMM`` now carry its name, which is the root's directory name unless
      the new ``--name`` option gives another: ``jobserver-SEAMM_NEW``,
      ``SEAMM (SEAMM_NEW)``, ``SEAMM-JobServer-SEAMM_NEW``. Before, any root other than
      ``~/SEAMM`` and ``~/SEAMM_DEV`` used the same names as ``~/SEAMM``, so creating
      its services replaced production's. ``~/SEAMM_DEV`` now follows the same rule
      (``jobserver-SEAMM_DEV`` rather than ``dev_jobserver``).
    * ``services create`` stops and replaces any other SEAMM service of the same kind
      started with the same root, whatever its name, so two JobServers never share one
      datastore. It gives the web interface the service's existing port, or else the
      first free port from 55055, so a second installation's web interface does not
      clash with the first's.
    * ``services status --all`` and ``services show --all`` list every installation's
      services, with their roots. The manager's window shows which installation it is
      working on, and its Services tab can now create the web interface service.
    * The root defaults to ``$SEAMM_ROOT`` when set.
    * ``update --latest`` asked PyPI's JSON API, which could return a stale copy
      shortly after a release; it now asks the simple index that uv installs from.
    * Bugfix: after installing seamm-jobserver, the manager restarted a service named
      after the package, which never exists, so the JobServer was not restarted.

2026.9.27.4 -- Bugfix: plug-in installers use the installation being worked on
    * The plug-ins' installers always wrote their code's ``.ini`` file (``mopac.ini``,
      ``lammps.ini``, ...) into ``~/SEAMM``, even for ``seamm-manager --root X`` or
      ``--development``. The manager now tells them its root, so the files go into the
      installation being installed or updated.
    * An installer run by hand from an installation's environment
      (``<root>/venv/bin/<plug-in>-installer``) works on that installation. ``root`` in
      the per-user ``seamm.ini`` is still honoured but deprecated, as it is shared by
      every installation.

2026.9.27.3 -- Bugfix: services restart now restarts the services
    * ``seamm-manager services restart`` did nothing: it ran the start command, which
      reported that the service was already running. It now stops and starts each
      service, on macOS and Linux. (The restart that ``update`` does after upgrading the
      JobServer was not affected.)
    * When starting, stopping or restarting a service failed, the command and the
      manager's Services tab crashed with an AttributeError instead of showing what
      went wrong. They now print the error.

2026.9.27.2 -- The Mac services show up by name, with the SEAMM icon
    * On macOS the JobServer and the web interface showed up in Activity Monitor and
      ``ps`` as ``python3.12``. They now run as ``SEAMM-JobServer`` and ``SEAMM-WebUI``
      with the SEAMM icon: ``services create`` puts the environment's Python
      interpreter in a small background app under ``~/SEAMM/services`` (a hard link,
      so no extra disk space) and runs the service with it. Jobs are started exactly as
      before.
    * Existing services keep working as they are. ``seamm-manager update`` says how to
      convert them (``seamm-manager services create --force jobserver webui``, when no
      jobs are running), and keeps the bundles' interpreter in step with the
      environment.
    * ``services create --force`` sometimes left the new service stopped, without any
      message: launchd was still removing the old one when it was started. Stopping a
      service now waits until launchd has finished.

2026.9.27.1 -- Bugfix: the Mac apps no longer ask for Rosetta
    * On an Apple Silicon Mac without Rosetta, starting SEAMM or SEAMM-Manager from its
      app showed a dialog asking to install Rosetta. The app's executable was a shell
      script, which carries no architecture, so macOS assumed it might need Intel code.
      The apps now use a small compiled launcher, built for both Apple Silicon and
      Intel, which runs the same script from the app's Resources folder. Nothing in
      SEAMM needs Rosetta.
    * ``seamm-manager update`` converts existing apps automatically (and keeps their
      version current); ``seamm-manager apps update`` does the same on its own.
    * The app's process is now SEAMM itself rather than a shell waiting on it.

2026.9.27 -- update --latest picks up a same-day release from PyPI
    * ``seamm-manager update`` takes the available version of each package from the
      package list published nightly, so a release made today was reported as
      "Everything is up to date" until the next day, and ``--no-constraints`` did not
      help. The new ``--latest`` option asks PyPI for each package's newest release,
      pins it exactly when it is newer than the list's, and updates without the lock
      file (which would pin yesterday's version). If PyPI cannot be reached the
      package list is used as before.

2026.9.26.6 -- Bugfix: environment files no longer upgrade a machine's torch
    * Applying a plug-in's environment file to an existing conda environment no
      longer upgrades bare pip requirements. Conda runs a file's ``pip:`` section
      with ``pip install -U``, so ``torch`` in xnn_step's file was upgraded, in the
      ``seamm-lammps`` environment that xnn.ini on ChemAI shares with LAMMPS, to a
      CUDA 13 build the driver cannot run. Now a bare name is installed only if
      missing, while a requirement with a version specifier (``xnns>=0.3.0``,
      ``e3nn==0.4.4``) is kept current within it. The plug-in that adds the MLFF
      engine to LAMMPS's environment keeps doing so; the machine's driver-matched
      torch is left alone.

2026.9.26.5 -- Bugfix: the manager's release was only synced alongside other updates
    * The step added in 2026.9.26.4 that puts the running manager's release into the
      environment ran only when some other package was being installed or updated, so
      an environment with nothing else to update kept the older manager. It now runs
      every time.

2026.9.26.4 -- The environment keeps the manager's own release; manual codes
    * After installing or updating, the manager puts its own release into the
      environment if the package list still names an older one. The list is refreshed
      nightly, so for up to a day after a manager release the environment -- and with it
      the plug-ins' installers -- used to get the previous version.
    * A plug-in installer for a code that is not installed automatically (ORCA,
      Gaussian, VASP) now says so when asked to install, instead of failing with an
      AttributeError about a missing environment file.

2026.9.26.3 -- Bugfixes from the first Linux migration (ChemAI)
    * ``update --all`` upgrades the manager itself with a forced, index-refreshing
      reinstall; ``uv tool upgrade`` could report "Nothing to upgrade" minutes after a
      release because uv reused its cached view of PyPI.
    * The datastore version check ran ``alembic`` from the PATH, which the
      manager's own tool environment does not have; it now runs the environment's
      alembic, like the migration itself. On ChemAI this made a fresh install end
      in "updated to version unknown, but it should be None".
    * ``services create`` on Linux crashed after deleting the old unit and before
      writing the new one (the executable path is now a ``Path``), leaving no
      service. Found on ChemAI; the unit was restored by hand.

2026.9.26.2 -- Bugfixes from a first installation on a brand-new Mac
    * On a fresh Mac ``uv tool install seamm-manager`` built the manager on the
      system Python 3.9, because nothing declared a minimum version. The package now
      requires Python 3.12 or later, so uv installs one if needed.
    * A plug-in's own installer that fails (for instance because conda is not
      installed) now reports what went wrong, instead of leaving the code silently
      uninstalled.
    * The datastore is created at installation, and before a service is started,
      rather than by the web interface's first start; a JobServer created first
      used to crash-loop on the missing database.

2026.9.26.1 -- Bugfixes from the first real migration
    * Conda could not be found by a manager or plug-in installer launched from the
      Dock or as a service, whose PATH is minimal, so the GUI showed a traceback in
      each plug-in's description. Conda is now found through ``$CONDA_EXE``, the PATH,
      or the usual installation directories, and its directory is passed on to
      sub-processes. With no conda environment active the base installation is taken
      from ``root_prefix`` rather than the (empty) active prefix.
    * The services and datastore commands used the raw ``--root`` option, which is
      empty when the default root applies; the post-install step crashed. They now
      use the resolved root.
    * A plug-in installer writing a fresh ``<code>.ini`` crashed serializing an empty
      configuration.
    * The manager's desktop app is ``SEAMM-Manager``, running ``seamm-manager``.
    * ``install`` runs the per-package steps (datastore update, the plug-ins' own
      installers) for the packages it installed or updated; ``--rerun-installers``
      runs them for every requested package, which recovers an interrupted install.

2026.9.26 -- First release of seamm-manager
    * seamm-manager replaces seamm-installer. It manages a SEAMM installation in a
      uv-managed Python virtual environment under the SEAMM root (``~/SEAMM/venv``):
      every package comes from PyPI, resolved against the published lock file, so an
      installation is reproducible and takes seconds rather than minutes. Conda is
      used only for the external codes' own environments (MOPAC, Psi4, LAMMPS, ...).
    * ``seamm-manager install --all`` creates the environment (Python 3.12 via uv) and
      installs SEAMM with all the MolSSI plug-ins in one constrained step; ``update``
      keeps the manager and the packages current; a new ``environment`` command shows,
      creates, recreates or removes the environment. Services, desktop apps and the
      datastore migration use the environment's own executables.
    * seamm-installer stays available for existing conda-based installations, which
      keep working but no longer receive updates; see the migration guide in the
      installation documentation. A ``seamm_installer`` compatibility module keeps the
      plug-ins' own installers working inside the new environment.
