I genuinely don't understand how someone can be a "proponent" of pipenv. In the mangled space of python package maintenance, pipenv is probably the absolute worst solution

- pipenv install updates your lockfile on install exactly like how `npm install` updates the package-lock.json and requires additional flags to use the lockfile instead

- pipenv's dependency resolution is the slowest among all the tools in this space including poetry, pip-tools, hatch and so on

- pipenv has consistently failed to do its job to simply install dependencies because of issues like the one described in the article where it fails to resolve changes in hash simply because a new wheel was added for the platform

- Tons of longstanding bugs that fail to be resolved in any sort of timely manner like this one: https://github.com/pypa/pipenv/issues/2413

I am sick and tired of the python packaging space pushing this godawful tool for Python. Please just use pip-tools or poetry instead.

Not to mention the horrible configuration anti-pattern where everything depends on environment variables.

Environment variable tweaks are for local-only specific fixes, not for reproducible/distributable configuration.

> not for reproducible/distributable configuration

At my work, we use environment variables all the time for configurations, e.g. for telling a kubernetes pod where to find the database. In your opinion, what is the better option(s)?

Secret managers. All cloud providers have them built in, and on other platforms you can easily whip up a self-hosted one. See https://blog.diogomonica.com//2017/03/27/why-you-shouldnt-us...

I recommend against with using secrets managers as opposed to config files for storing configuration. Ideally, your configuration is versioned and code-reviewed. Config files are optimal. Even secrets used by your deployment should be stored in configuration - encrypted, of course. The benefit of versioned configuration files, secrets included, cannot be overstated.

You can encrypt sensitive configuration fields with tools like `mozilla/sops` [1], which will reach out to your KMS or secrets manager of choice to encrypt/decrypt sensitive fields on the fly.

This way, you are minimizing the splitting of state across secrets managers and your code. Your configuration is stored at code, code reviewed, and versioned, which has devops and security benefits of its own.

[1]: https://github.com/mozilla/sops