Summary
Application configuration is a deceptively complex problem. Everyone who is building a project that gets used more than once will end up needing to add configuration to control aspects of behavior or manage connections to other systems and services. At first glance it seems simple, but can quickly become unwieldy. Bruno Rocha created Dynaconf in an effort to provide a simple interface with powerful capabilities for managing settings across environments with a set of strong opinions. In this episode he shares the story behind the project, how its design allows for adapting to various applications, and how you can start using it today for your own projects.
Announcements
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great!
- When you’re ready to launch your next app or want to try a project you hear about on the show, you’ll need somewhere to deploy it, so take a look at our friends over at Linode. With their managed Kubernetes platform it’s easy to get started with the next generation of deployment and scaling, powered by the battle tested Linode platform, including simple pricing, node balancers, 40Gbit networking, dedicated CPU and GPU instances, and worldwide data centers. And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover. Go to pythonpodcast.com/linode and get a $100 credit to try out a Kubernetes cluster of your own. And don’t forget to thank them for their continued support of this show!
- Your host as usual is Tobias Macey and today I’m interviewing Bruno Rocha about Dynaconf, a powerful and flexible framework for managing your application’s configuration settings
Interview
- Introductions
- How did you get introduced to Python?
- Can you describe what Dynaconf is and the story behind it?
- What are your main goals for Dynaconf?
- What kinds of projects (e.g. web, devops, ML, etc.) are you focused on supporting with Dynaconf?
- Settings management is a deceptively complex and detailed aspect of software engineering, with a lot of conflicting opinions about the "right way". What are the design philosophies that you lean on for Dynaconf?
- Many engineers end up building their own frameworks for managing settings as their use cases and environments get increasingly complicated. What are some of the ways that those efforts can go wrong or become unmaintainable?
- Can you describe how Dynaconf is implemented?
- How have the design and goals of the project evolved since you first started it?
- What is the workflow for getting started with Dynaconf on a new project?
- How does the usage scale with the complexity of the host project?
- What are some strategies that you recommend for integrating Dynaconf into an existing project that already has complex requirements for settings across multiple environments?
- Secrets management is one of the most frequently under- or over-engineered aspects of application configuration. What are some of the ways that you have worked to strike a balance of making the "right way" easy?
- What are some of the more advanced or under-utilized capabilities of Dynaconf?
- What are the most interesting, innovative, or unexpected ways that you have seen Dynaconf used?
- What are the most interesting, unexpected, or challenging lessons that you have learned while working on Dynaconf?
- When is Dynaconf the wrong choice?
- What do you have planned for the future of Dynaconf?
Keep In Touch
Picks
