cmstp 1.0.1

Contains anything related to setting up a new computer (desktop) system

cmstp - computer setup

Contains anything related to setting up a new computer (desktop) system.

Disclaimer - Use at your own risk

This project is currently (12.2025) coded solely by me. As a junior developer, there is probably a lot that can be improved and although I have tested each task, there may be some unforeseen issues. Please use with caution and report any issues you find (see the contributing section).

During this project's initial development, I recommend using it solely on fresh machines.

Installation

Prerequisites

Ubuntu 24.04+

We recommend installing pipx via apt:

sudo apt update && sudo apt install pipx

Older Ubuntu Versions

We recommend installing pipx via pip:

sudo apt update && sudo apt install python3 python3-pip && python3 -m pip install --user pipx

NOTE: The installation of pipx via pip (as opposed to apt) is recommended on older versions, as the apt version is often outdated.

MacOS

Not supported yet.

Windows

Not supported yet.

Main Installation

Then, install cmstp via pipx:

pipx install cmstp

Usage

Pre-Setup

We recommend setting up the following before running the main installation/configuration tasks:

• Configuring SSH keys for git (GitHub, GitLab, etc.) - some tasks may require cloning private repositories
• Disabling Secure Boot (e.g. for installing NVIDIA drivers)

You can use the provided helper to guide you through these steps:

cmstp pre-setup [-s] [-g]

The helper also provides further possible manual setup steps for configuring fresh systems.

NOTE: You may also look up the general instructions for creating SSH keys here.

Main Installations/Configurations

To use default installations/configurations, simply use (without any flags):

cmstp setup [-h] [-t TASKS [TASKS ...]] [-f CONFIG_FILE] [-d CONFIG_DIRECTORY] [-p] [-v]

To use custom config installation/configuration config files, use (flag shorthand: -d)

cmstp --config-directory </path/to/configs/ | git_url>

where /path/to/configs/ is a directory containing multiple txt/json(c)/yaml/... configuration files (to be used by tasks as defined in this repo's config/default.yaml file) following this package's default config/ directory. Each file in that directory should have the same name and structure as in the default. We STRONGLY RECOMMEND saving a personalized config directory as a git repository and providing the git URL instead of a local path. The repository will be cloned and used for the configurations. For more details and examples of configs, see this README.

To easily specify multiple tasks to be run, use (flag shorthand: -f)

cmstp --config-file /path/to/config.yaml

where the config file should be a yaml file following the structure of the config/enabled.yaml file in this package. That config file contains detailed explanations. Should a relative path be provided, the file will first be searched for locally and then in the config directory.

To simply enable tasks with their default configurations, use (flag shorthand: -t)

cmstp --tasks TASK1 TASK2 ...

where TASK1, TASK2, ... are the task names as specified in the config/enabled.yaml file in this package. If both --config-directory and --tasks are provided, the --tasks flag takes precedence for enabling tasks.

Contributing

Please see CONTRIBUTING.md for contribution guidelines.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Possible Future Features

• Add uninstallations/deconfigurations and seprate configurations from installations. That could result in multiple entrypoints (instead of the current single cmstp setup):
  • cmstp install - for installations only
  • cmstp configure - for configurations only
  • cmstp uninstall - for uninstallations only
  • Possibly, a cmstp deconfigure for deconfigurations only
• Setup Browser Bookmarks
• Setup Autocompletions

TODO

Look for TODOs in code. Otherwise, look at:

!!! Major !!!

• Update this README
• When using -t task, allow args to be passed, e.g. via -t task:arg1:arg2. Also, allow e.g. enable_deps to be passed
• Update and document pytests, and use them in CI (e.g. make sure there is no ✖ Failure in output)
• Add descriptions to each function (inputs, outputs, what it does) both for python and bash
• Have a --force (and/or --reinstall) argument to override checks (i.e. run even if already installed/configured)
• See where revert_sudo_permission is necessary (isaac*, miniconda, .virtualenvs, configure-filestructure, ...) - include parent folders

Minor

• Add mujoco stuff (mujoco, dmcontrol, sim applications)
• (If possible) Only run CI on new or edited tasks
• Add file with list of debian file links (then get and dpkg (or step apt?) them)
• Maybe, when cmstp is run for the very first time, propose to do pre-setup first (then create mock file in pkg or so to mark that cmstp was already run once)
  • Or just add big NOTE in README -> but that may not be seen by those installing via pipx
• Define and document behaviour of using none, one of, or both --config-file and --config-directory
  • How can a config file in a config dir repo be specified?
    • (Maybe) If it's an absolute path, look there. If it is relative, look locally and then in the repo
• Reduce the config files here to the most basic, non-invasive ones (just to have some example)
• Test cyclic supercedes fields
• Update logging to file (i.e. CMSTP START ...) to only have a single CMSTP section, and fill stuff in there
• Remove uninstallations from "enable_all" etc. Or better, have a "counterpart" field or similar and if both install/uninstall are enabled, disable uninstall (say this in debug, not info/warning message)
• It seems that something may suspend all tasks running (if many are running)
  • Maybe this is caused by one task failing?
  • Can be restarted sing fg %<id> (bash; manually) (see id from output: [<id>]+ Stopped), but ofc that should not be necessary in the long term
• Maybe add a requires-restart flag or so to each task and make final message depend on that
• If a dependency task fails, downstream tasks should not be run
• If verbose is set, save the modified scripts in log dir
• Make dev instructions (e.g. to add a task, edit <...>; to add a field to tasks, edit <...>; to add a test, edit <...>; etc.)
• Remove sudo: mon_handle_sigchld: waitpid: No child processes outputs
• (If possible) Add a workflow that checks that there is a version bump in pyproject.toml