Configure all peach config and data paths via environmental variables #104

New Issue

notplants · 2022-04-20T19:43:23Z

notplants commented

2022-04-20 19:43:23 +00:00

I think we should try to make all peachcloud and go-sbot paths to where data and configurations are stored be set via variables, which can be configured by environmental variables.

E.g.

		peach-lib/src/sbot.rs
		Line 205 in e2ac5de6e4
	
				        let mut config_path = dirs::home_dir().ok_or(PeachError::HomeDir)?;

		peach-lib/src/sbot.rs
		Line 223 in e2ac5de6e4
	
				        let mut config_path = dirs::home_dir().ok_or(PeachError::HomeDir)?;

		peach-config/src/set_permissions.rs
		Line 8 in e2ac5de6e4
	
				pub const PEACH_HOME_DIR: &str = "/home/peach";

For instance in yunohost, this data and configuration should not necessarily be stored in /home/peach , but rather in /home/yunohost.app/peachpub , or even in multiple locations (/home/yunohost.app/peachpub1 /home/yunohost.app/peachpub2), if there was a yunohost instance with multiple peachpub installed. Of course I don't think we should prioritize the multi-install usecase, but making peachpub so that it can work in a multi-install usecase I think means we are using a good design (all data and configuration paths are configurable -- which generally makes the software more flexible and easier for users to customize and install in different situations). In particular, perhaps we should specificy paths not in terms of a HOME directory, but in terms of what the path functionally represents (e.g. GOSBOT_DATA_DIR, PEACH_CONFIG_DIR). If it happens that for a particular installation that is the home dir, we can set that in one place, but we can name the paths more functionally so that they could be flexible to different locations, depending on the needs of the user/installation.

@glyph this may be a first TODO we need to work on before we can really move forward with the yunohost packaging (or in the future, for example for a proper debian package for planetary).

I think we should try to make all peachcloud and go-sbot paths to where data and configurations are stored be set via variables, which can be configured by environmental variables. E.g. https://git.coopcloud.tech/PeachCloud/peach-workspace/src/commit/e2ac5de6e4c16b6a511b41fd8bd87b31efdd8de8/peach-lib/src/sbot.rs#L205 https://git.coopcloud.tech/PeachCloud/peach-workspace/src/commit/e2ac5de6e4c16b6a511b41fd8bd87b31efdd8de8/peach-lib/src/sbot.rs#L223 https://git.coopcloud.tech/PeachCloud/peach-workspace/src/commit/e2ac5de6e4c16b6a511b41fd8bd87b31efdd8de8/peach-config/src/set_permissions.rs#L8 For instance in yunohost, this data and configuration should not necessarily be stored in /home/peach , but rather in /home/yunohost.app/peachpub , or even in multiple locations (/home/yunohost.app/peachpub1 /home/yunohost.app/peachpub2), if there was a yunohost instance with multiple peachpub installed. Of course I don't think we should prioritize the multi-install usecase, but making peachpub so that it can work in a multi-install usecase I think means we are using a good design (all data and configuration paths are configurable -- which generally makes the software more flexible and easier for users to customize and install in different situations). In particular, perhaps we should specificy paths not in terms of a HOME directory, but in terms of what the path functionally represents (e.g. GOSBOT_DATA_DIR, PEACH_CONFIG_DIR). If it happens that for a particular installation that is the home dir, we can set that in one place, but we can name the paths more functionally so that they could be flexible to different locations, depending on the needs of the user/installation. @glyph this may be a first TODO we need to work on before we can really move forward with the yunohost packaging (or in the future, for example for a proper debian package for planetary).

glyph commented

2022-04-29 06:35:09 +00:00

@notplants

Cool, this sounds good to me. We could take a similar approach to the way config is defined in peach-web and define a default path which is then overwritten by the corresponding env var (if set). Example code here.

Use peach_lib::config_manager as the single source of application configuration
- Define the location of the config file
  - First set the default path, overwrite with env var value if set
- When constructing the config for the first time:
  - First define default values, overwrite with env var values if set
- When reading the config:
  - First check for env var values, fallback to file values
- Use functional path names (ie. GOSBOT_DATA_DIR instead of HOME)

@notplants Cool, this sounds good to me. We could take a similar approach to the way config is defined in peach-web and define a default path which is then overwritten by the corresponding env var (if set). Example code [here](https://git.coopcloud.tech/PeachCloud/peach-workspace/src/branch/main/peach-web/src/config.rs#L31). - Use `peach_lib::config_manager` as the single source of application configuration - Define the location of the config file - First set the default path, overwrite with env var value if set - When constructing the config for the first time: - First define default values, overwrite with env var values if set - When reading the config: - First check for env var values, fallback to file values - Use functional path names (ie. `GOSBOT_DATA_DIR` instead of `HOME`)

notplants referenced this issue

2022-05-09 13:53:50 +00:00

Update config_manager to check from three sources of configuration #105

notplants referenced this issue

2022-05-12 10:52:41 +00:00

Broken PR: Update peach-config to use configured paths #110

notplants referenced this issue

2022-05-12 11:33:43 +00:00

Update peach-config to use configured paths #111

glyph commented

2022-06-16 11:06:37 +00:00

@notplants