Configure all peach config and data paths via environmental variables #104
Labels
No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PeachCloud/peach-workspace#104
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
e2ac5de6e4/peach-lib/src/sbot.rs (L205)
e2ac5de6e4/peach-lib/src/sbot.rs (L223)
e2ac5de6e4/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).
@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.
peach_lib::config_manager
as the single source of application configurationGOSBOT_DATA_DIR
instead ofHOME
)@notplants
Can we close this issue now? I seem to think you've completed the path update work :)
Yup I think this is done, closing now.