Currently there is an option to provide either a hub_connection class object to hub_con, which has config_tasks attached as an attribute) or a config class object to config_tasks. It feels easier to just ask for hub_path instead of requiring folks to use hubData::connect_hub() to create a hub_connection given we only need the actual config_tasks object from the connection.
I would suggest we just do away with config_tasks (which also requires an extra step to read the config) and restrict the argument to hub_path only, then use read_config() internally to get the config.
Currently there is an option to provide either a hub_connection class object to
hub_con, which hasconfig_tasksattached as an attribute) or aconfigclass object toconfig_tasks. It feels easier to just ask forhub_pathinstead of requiring folks to usehubData::connect_hub()to create ahub_connectiongiven we only need the actualconfig_tasksobject from the connection.I would suggest we just do away with
config_tasks(which also requires an extra step to read the config) and restrict the argument tohub_pathonly, then useread_config()internally to get the config.This would also resolve #137