Dotenv migration

[ziaddevv]

Summary

Replace the scattered credentials.py configuration system with a centralized dotenv-based approach.
This PR introduces the foundation (config.py + .env files) and a backward-compatible adapter so all existing consumers continue working without changes

Changes

New: wp1/config.py

Central Config class that reads settings from environment variables via python-dotenv. Includes type-safe helpers (_getenv, _getenv_int, _getenv_list),
auto-detects pytest and loads .env.test, and validates WP1_ENV values with clear error messages

New: .env.example, .env.test, .env.docker

.env.example
Developer setup template that combines all previous credential example files into one organized file with clear sections and setup options.

Comments were rewritten to be more accurate and actionable rather than copied blindly from the multiple old files (needs more review)

.env.test
Test overrides auto-loaded when pytest is detected. All keys explicitly overridden to prevent leakage from Pipenv’s .env auto-load

.env.docker

Docker hostname overrides for example minio, redis, dev-database instead of localhost

Modified: wp1/credentials.py (un-gitignored)

now it is a backward-compatible adapter importing from config.py and reconstructing the CREDENTIALS[ENV] nested dict expected by consumers. Since it no longer contains secrets, it is now committed

Migration Plan
This is PR 1 of the dotenv migration . No consumer files are changed in this PR . the adapter ensures full backward compatibility.

fixes #1016

[audiodude]

Hi @ziaddevv, could you please explain the process behind closing this request, reopening it, and re-closing it? Was it just a git merge/config issue? Was it a problem with code architecture?

This information will help those in the future who wish to potentially tackle this problem, or at the very least those who wish to track and understand whatever becomes the final version of this feature. Thanks!

[ziaddevv]

Hi @ziaddevv, could you please explain the process behind closing this request, reopening it, and re-closing it? Was it just a git merge/config issue? Was it a problem with code architecture?

This information will help those in the future who wish to potentially tackle this problem, or at the very least those who wish to track and understand whatever becomes the final version of this feature. Thanks!

Hi @audiodude

This was only due to a git conflict during the update process. I initially closed the PR, reopened it while resolving the conflicts and syncing with the latest changes, and then closed it again after deciding to open a clean PR instead.
To avoid confusion and keep the history clearer, I created a new PR here: #1102 which contains the updated version of the changes.

There were no issues related to the code architecture or the feature itself . it was purely a git merge/conflict situation.