What does this look like for packet-python? (Following a rename #106)
# ~/.config/equinix/metal.yaml
---
token: ...
This common file would serve as the default token for all Equinix Metal API client tools, regardless of language, regardless of tool.
Different tools will have their own means of setting provider tokens and this shared/central configuration will not prevent that.
In the packngo issue, the format is described as one that could be shared between Equinix tools. Metal tools could be configured in a metal specific block and individual clients could be configured within sub-blocks.
# ~/.config/equinix/metal.yaml
---
token: ... # default
clients: # this format has not been formalized, perhaps "profile" would be a better name. Tools could allow users to specify the profile to use.
- name: ansible
token: ... # client specific
The configuration file would allow for defaults such as organization id, project id, facility, metro, device plan, and OS to be specified. Tools do not have to honor these defaults but they will be able to take advantage of them so long as defaults are configured and the tool documentation declares that these values will be used.
packet-python would offer accessors and classes for accessing the configured parameters.
packet-python may offer new client constructors (or new default behaviors in a renamed module #106) that defer to this configuration under various conditions (to be defined).
packet-python may allow for environment variables to override the default configuration file.
packet-python may allow for environment variables to override the configuration file values.
More ambitious aspects of the packngo issue express that the client should be able to fetch defaults from the Equinix Metal API. The user profile is configured with default organizations and projects, as defined in the Equinix Metal Portal.
This style of configuration is found in other cloud provider toolsets where common configuration is shared between tools. This simplifies the experience of using different tools because the defaults and secrets are already defined allowing client tools to work with little or no configuration.
As expressed in https://github.com/packethost/packngo/issues/189#issuecomment-802234842, users would benefit from a common configuration file location and format shared between tools.
What does this look like for packet-python? (Following a rename #106)
This common file would serve as the default token for all Equinix Metal API client tools, regardless of language, regardless of tool.
Different tools will have their own means of setting provider tokens and this shared/central configuration will not prevent that.
In the packngo issue, the format is described as one that could be shared between Equinix tools. Metal tools could be configured in a metal specific block and individual clients could be configured within sub-blocks.
The configuration file would allow for defaults such as organization id, project id, facility, metro, device plan, and OS to be specified. Tools do not have to honor these defaults but they will be able to take advantage of them so long as defaults are configured and the tool documentation declares that these values will be used.
More ambitious aspects of the packngo issue express that the client should be able to fetch defaults from the Equinix Metal API. The user profile is configured with default organizations and projects, as defined in the Equinix Metal Portal.
This style of configuration is found in other cloud provider toolsets where common configuration is shared between tools. This simplifies the experience of using different tools because the defaults and secrets are already defined allowing client tools to work with little or no configuration.