You should always know the source of truth

Single source of truth

There should be one, and preferably only one, obvious source of truth for things.

This philosophy is a play on the Zen of Python, in which one line states:

There should be one -- and preferably only one -- obvious way to do it.

Part of how we manage complexity in our projects is by distilling things down to single sources of truth. By defining single sources of truth, we avoid the hairy situation of being unsure which version/copy of a thing we ought to depend on. This has the effect of minimizing confusion, and even potential conflicts, downstream.

For practical implementation of this principle in code organization, see how to structure your source code repository. This shows how to evolve from notebooks to maintainable code while maintaining clear sources of truth.

For centralizing data access patterns, see how to create a data catalog. This demonstrates how to create single sources of truth for data loading across your project.

For organizing your project's version control, see repository best practices. A well-structured repository supports the single source of truth principle.

As you go through the knowledge base, you will see this philosophy at play in how we structure and organize our individual projects.

See this philosophy in action

Single source of truth isn't abstract - it's visible in every well-organized project I've worked on:

Configuration consolidation

Here's what I've found works best: instead of scattered config files, see how Configuration files demonstrates putting all tool configurations in pyproject.toml - one file controls black, isort, pylint, pytest, and more. No more hunting through multiple config files when something breaks.

Data access functions

The Data catalog shows how I replace scattered data loading code with centralized functions. One load_customer_data() function becomes the authoritative way to access customer data across all notebooks and scripts. The beauty of this approach is that when the data source changes, you update one function, not twenty scattered loading snippets.

Environment variable management

Watch this principle in action through Environment variables - one .env file defines all project environment variables, automatically loaded by python-dotenv. No more "which database am I connected to?" confusion that kills productivity.

Dotfiles as central configuration

Your Dotfiles become the single source of truth for shell configuration. One repository defines your entire shell environment across all machines. Remember: the goal isn't to replace your current setup, but to amplify your consistency.

The result: You always know where to find the authoritative version of anything.