But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?

Of course you do that type of testing.

The problem comes about when someone does the following:

- creates python project

- pip install some_package

- import some_package

Turns out some package was already in the path but a different version

- proceeds to test and build with the assumption of some_package @ newer

- all tests pass

- ships project with requirements of some_package @ newer

Someone attempts to use the package but it doesn’t work.

Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment?

That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs.

But maybe I’m not understanding your suggestion.

OP was referring to containerizing your environment for package development.

What does connecting to a production DB have to do with any of that?