Giters

F1bonacc1 / process-compose

Process Compose is a simple and flexible scheduler and orchestrator to manage non-containerized applications.

Home Page:https://f1bonacc1.github.io/process-compose/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Missing documentation for settings.yaml

DamienCassou opened this issue · comments

commented

Feature Request

There seems to be some support for a user's settings.yaml file in ~/.config but this is not documented. What can we put there? The theme?

Proposed Change:

Add a section in the manual to describe what settings can be globally configured and how.

Who Benefits From The Change(s)?

Everyone needing some global configuration that shouldn't be saved in a particular process composition (e.g., the theme).

Alternative Approaches

A default settings.yaml could be added if none exists yet.

commented

I think it should be disabled by default, since creating/reading global settings is impure wrt to testings in CI, for example.
Ref: 23093e3

commented

Same here, had to provide a writable dir when running in nix sandbox

commented

I also get warnings that there is not settings.yaml file

commented

Hi,

The settings file was added in v1.0.0 to keep the TUI state.
It is not mandatory and was added to keep the selected theme and the selected sort order.
Additional values might be added in the future.
Today it is created automatically only when the above 2 values change.

Please don't hesitate to let me know if you have any concerns with the above behavior.

commented

@F1bonacc1 the problem is that PC fails to start if HOME is not writable. This is annoying especially when one doesn’t even use the TUI. I use PC to run integration tests inside nix sandbox and had to set PROC_COMP_CONFIG to some writable location to stop it from crashing

commented

I see the issue.
The xdg package that I use to read the OS-specific home configuration location also creates it if missing.

Will be fixed in the next release.

Thanks for letting me know.

commented

@F1bonacc1 I would advise against automatically changing a configuration file. To me, there are 2 kinds of files: (1) those of the user and (2) those of the software. Configuration files are for the user. A software should never write user files or many problems may arise:

  • the carefully-written comments may be lost
  • the careful sorting and grouping of settings may be lost
  • a symlink from the expected setting file location to a VCS-controlled directory (e.g., a git repo) may be replaced by a file (which would result in no more VCS guarantees without the user noticing)
  • the software may crash because the user file is on a read-only file-system

Users of process-compose are power users: they know how to create files and how to read documentation. After changing the theme and seeing that the default one is back when starting process-compose again, they will search for a settings file naturally.

Please leave my files alone. I just need a couple of sentences to tell me where to create my configuration file and what to put there.

commented

Hey @DamienCassou,

Thank you for your feedback.
What is your recommendation going forward?

  1. Power users - Disable settings.yaml writing on PC TUI state change.
  2. Middle ground - Provide a shortcut or command (a new concept I have considered adding to PC) to save the current application state.
  3. Ease of use - Disable the write access to ~/$USER/.config/process-compose if TUI is not used. Write the settings file when the TUI state changes.
commented

I don't understand "Disable the write access if TUI is not used". I think 1 and 2 make sense and I would be happy with both. Thank you for considering my feedback.

commented

Added --read-only flag in v1.5.0 to prevent all the writes from process compose.
Added settings documentation: https://f1bonacc1.github.io/process-compose/tui/#tui-state-settings