Rollbar SDK Does Not Support Basic Configuration from Environment Variables
haggishunk opened this issue · 2 comments
User Story
The rollbar sdk can be configured using environment variables.
During initialization, no variables are required. The sdk will log errors if the crucial access token is not supplied as an argument or defined as an env var.
# current calling
import rollbar
rollbar.init('<your_access_token>')
# desired calling
import rollbar
rollbar.init()
# which should succeed as long as
import os
assert os.environ.get('ROLLBAR_ACCESS_TOKEN') is not None
Background
Developers releasing code into many environments is a given. More and more the deployments are using cloud platforms that support config by env var. This pattern is espoused by the 12 factor app and is a powerful way to segment your apps at runtime.
Not all configuration options need to be supported. Simple and deployment-related ones such the access_token, environment, code_version, enabled, endpoint, verify_https make the most sense as they have more to do with the runtime artifact and the deployment environment, as opposed to the code makeup.
Hey @haggishunk, first thank you for the well thought through request. Second, I am so sorry It took me this long to get back to you.
As I have thought about this, there is a part of me that wonders why this needs to be part of the SDK instead of the application. I suspect any app following the 12 factor pattern (I am a fan and have built several apps that follow the pattern) would have a method for pulling in the configuration. That configuration could be via environment variables or a config file or some other method based on the environment. Most apps will need to pull in these configurations in order to connect to persistent data stores, etc.
What I am wondering is if the app already needs those configs pulled in, why have the Rollbar SDK collect its own configs via some other method?
Speaking on my own behalf. I think I would prefer to handle all the configs in a unified manner and pass things to the individual libraries and parts of the app that need them. However, this is a personal preference, and I can defiantly see it the other way as well.
What are your thoughts on this line of thinking?
No worries @danielmorell, glad to spark up a conversation.
My rationale comes from two places:
One is my experiences "instrumenting" applications with observability tools as an SRE. I use double quotes because many such tools have an essentially no-conf-to-get-started model where you add a new dependency, supply an api token and you go from 0 to a reasonable amount of insight into your app's performance. While I see the argument that all configuration should be expressed/consumed through a single unified interface I also see some exceptions, such as the no-conf approach noted above, api key rotations, or custom endpoints (think gov or regulatory sepate api endpoints which admittedly Rollbar does not support yet). I have also witnessed some bewilderingly complex configuration patterns (eg inheritance in pyramid's pastedeploy configs) shared between applications that have made we wish for an "external" pathway to segmenting apps into Rollbar projects. That being said, many configuration tools have a way to explicitly do an os environment var lookup so the argument isn't bulletproof.
The second, and perhaps more compelling, reason is that other o11y tools and direct competitors support it (eg sentry python, datadogpy).
I proposed this as an ergonomic improvement that helps low friction adoption of Rollbar whether it be in solo greenfield projects or seasoned stacks of microservices.