4 ms·

As someone who has been on call for applications with such complicated configuration logic, this looks like a treasure chest of future frustration. One reason

As someone who has been on call for applications with such complicated configuration logic, this looks like a treasure chest of future frustration. One reason that 12 factor apps use environment variables to store configuration is because then you have a single source of truth on how your application is configured. Using the principles of the 12 factor app, someone who had no hand in writing the code doesn't have to wrap their heads around whatever convoluted logical path your application takes to figuring out which Redis instance it will connect to, especially during an outage in which their priority is to fix your service as quickly as possible. They can in an emergency SSH into whatever machine is hosting your application or exec into the docker container and inspect the environment to have an almost complete picture of how your application is configured. The "globals().update(vars(module))" line actually increased my blood pressure. Please show some consideration to your teammates that help you keep your applications running. Have had nothing but bad experiences keeping apps running that used dotenv in node land and viper in go land. The 12 factor app people did not speak lightly.

deleted 7y ago
[deleted]
whalesalad 6y ago
I agree with you 100%. There is nothing stopping you from using environment variables in these configuration files. I do it all the time, in fact. If you scroll down to real world examples I share a few examples, one is for connecting to Redis. (grep page for os.environ) This approach is not mutually exclusive with 12-factor. It is complementary to 12-factor. > They can in an emergency SSH into whatever machine is hosting your application or exec into the docker container and inspect the environment to have an almost complete picture of how your application is configured. Totally agree with this too. I build apps with ops in mind and this specific realtime debug ability. > The "globals().update(vars(module))" line actually increased my blood pressure. Being a little dramatic here, aren't we? Please elaborate on what is wrong here. I have been writing Python professionally for approaching 12 years, so I am very interested. It is certainly not something you would see every day, but this is not an area of the codebase you visit on a daily basis. Also, as a sidenote, I would strongly encourage you to look under the hood at some of your favorite/popular Python libraries. You'll vomit out your nose. > Please show some consideration to your teammates that help you keep your applications running. I forklifted FarmLogs from Heroku to a homebrew Kube cluster in 2016, led operations and support with that tool (40 microservices around the time I left) all while continuing to be an IC and ultimately became the CTO. I have an extreme amount of consideration for others when building software (almost to a fault). Clearly I have some work to do on my writing. > Have had nothing but bad experiences keeping apps running that used dotenv in node land and viper in go land. Yes. IMHO viper and dotenv strictly hobby tools that should be used for projects that involve a single developer and a single environment. I agree whole heartedly that they encourage bad practices and make things tough to debug and find. I cannot tell you how many times I had to matrix my way into a running container and try to figure out what the fuck was going wrong. Let me tell you ... when you have a microservice that depends on 50 environment variables to boot you are not going to be happy. If you can shove as much of that INTO the application as possible (without handicapping yourself or your fellow team mates in the production environments, losing flexibility in deployment target, etc..) why would you not want to do it? That is ultimately what I want people to gain from this.
- zomglings 6y ago
  Sorry if I was abrasive in my response. Let me address two of the points here: >> The "globals().update(vars(module))" line actually increased my blood pressure. > Being a little dramatic here, aren't we? Please elaborate on what is wrong here. and >> Please show some consideration to your teammates that help you keep your applications running. The reason I don't like this is that it first dynamically imports the right module and then implicitly sets global variables using the variables from that module using vars. This means that someone couldn't use simple greps or such searches to trace the logic through which a parameter was set (a go-to tool when debugging code someone else put into a docker container). - - - > Clearly I have some work to do on my writing. Your writing is good. I disagree with your approach to solving the problem. Willing to accept that my position is wrong, but am reluctant to do so since it's built on bitter experience.

deleted 7y ago

[deleted]

whalesalad 6y ago

I agree with you 100%. There is nothing stopping you from using environment variables in these configuration files. I do it all the time, in fact. If you scroll down to real world examples I share a few examples, one is for connecting to Redis. (grep page for os.environ) This approach is not mutually exclusive with 12-factor. It is complementary to 12-factor. > They can in an emergency SSH into whatever machine is hosting your application or exec into the docker container and inspect the environment to have an almost complete picture of how your application is configured. Totally agree with this too. I build apps with ops in mind and this specific realtime debug ability. > The "globals().update(vars(module))" line actually increased my blood pressure. Being a little dramatic here, aren't we? Please elaborate on what is wrong here. I have been writing Python professionally for approaching 12 years, so I am very interested. It is certainly not something you would see every day, but this is not an area of the codebase you visit on a daily basis. Also, as a sidenote, I would strongly encourage you to look under the hood at some of your favorite/popular Python libraries. You'll vomit out your nose. > Please show some consideration to your teammates that help you keep your applications running. I forklifted FarmLogs from Heroku to a homebrew Kube cluster in 2016, led operations and support with that tool (40 microservices around the time I left) all while continuing to be an IC and ultimately became the CTO. I have an extreme amount of consideration for others when building software (almost to a fault). Clearly I have some work to do on my writing. > Have had nothing but bad experiences keeping apps running that used dotenv in node land and viper in go land. Yes. IMHO viper and dotenv strictly hobby tools that should be used for projects that involve a single developer and a single environment. I agree whole heartedly that they encourage bad practices and make things tough to debug and find. I cannot tell you how many times I had to matrix my way into a running container and try to figure out what the fuck was going wrong. Let me tell you ... when you have a microservice that depends on 50 environment variables to boot you are not going to be happy. If you can shove as much of that INTO the application as possible (without handicapping yourself or your fellow team mates in the production environments, losing flexibility in deployment target, etc..) why would you not want to do it? That is ultimately what I want people to gain from this.

zomglings 6y ago
Sorry if I was abrasive in my response. Let me address two of the points here: >> The "globals().update(vars(module))" line actually increased my blood pressure. > Being a little dramatic here, aren't we? Please elaborate on what is wrong here. and >> Please show some consideration to your teammates that help you keep your applications running. The reason I don't like this is that it first dynamically imports the right module and then implicitly sets global variables using the variables from that module using vars. This means that someone couldn't use simple greps or such searches to trace the logic through which a parameter was set (a go-to tool when debugging code someone else put into a docker container). - - - > Clearly I have some work to do on my writing. Your writing is good. I disagree with your approach to solving the problem. Willing to accept that my position is wrong, but am reluctant to do so since it's built on bitter experience.