creating/guessing config dirs and config files has been quite wild (and not always consistent) throughout shng, and not all methods were prepared to honor extern_conf_dir or config_etc.
lib.smarthome has new methods:
get_config_dir(config)
get_config_file(basename)
both use existing methods or variables and create a single centralized point to access shng's config dirs and files (no more accessing sh._etc_dir or os.path.join-ing chains, mostly)
exceptions are sh.get_basedir and sh.get_confdir (for extern_conf_dir) as I see these to be special cases. They could be adjusted quite easily, though
lib.constants has a bunch of DIR_FOO and BASE_BAR constants designating config dirs and config file basenames. These can (should) be used in calls to the mentioned methods.
these are also present in the test mockup core
all lib/.py and module/admin/.py use these methods consistently
Running different setups and tests all went smoothly, threw/logged no errors and functioned as intended, so no obvious errors
All "legacy" methods and vars are still available, so not using the new methods will still function (non-breaking change); we might designate the old methods deprecated at some later time.
I intend to merge this soon; though non-breaking, I offer the PR up for testing on other setups beforehand.
creating/guessing config dirs and config files has been quite wild (and not always consistent) throughout shng, and not all methods were prepared to honor extern_conf_dir or config_etc.
get_config_dir(config)get_config_file(basename)both use existing methods or variables and create a single centralized point to access shng's config dirs and files (no more accessingsh._etc_diroros.path.join-ing chains, mostly) exceptions aresh.get_basedirandsh.get_confdir(for extern_conf_dir) as I see these to be special cases. They could be adjusted quite easily, thoughRunning different setups and tests all went smoothly, threw/logged no errors and functioned as intended, so no obvious errors
All "legacy" methods and vars are still available, so not using the new methods will still function (non-breaking change); we might designate the old methods deprecated at some later time.
I intend to merge this soon; though non-breaking, I offer the PR up for testing on other setups beforehand.