[dahfizz]

Sure, keeping a stack clean is always difficult. But I think OPs point was that programming in a container encourages a more fragile setup.

On a native setup, you get a feel for the fact that X config file might be in different places, or that Y lib is more robust and more widely available than lib Z. You end up with a more robust application because you have been "testing" it on a wide range of systems from day one.

[rumanator]

> But I think OPs point was that programming in a container encourages a more fragile setup.

I don't see how that point can be argued at all, particularly if the project is expected to be deployed with Docker.

[dahfizz]

I just argued that point.

When developing inside docker, you are fooled into thinking that various things about your environment are constants. When it comes time to update your base image, all these constants change, and your application breaks.

[rumanator]

> When developing inside docker, you are fooled into thinking that various things about your environment are constants.

No, you really aren't. You're just using a self-contained environment. That's it. If somehow you fool yourself into assuming your ad-hoc changes you made to your dev environment will be present in your prod environment although you did zero to ensure they exist then the problem lies with you and your broken deployment process, not the tools you chose to adopt.

A bad workman blames his tools. Always.

[jfim]

Is that a problem in practice though?

Updating libraries or the base image that one's code depends on always has the risk of breaking from API changes or regressions, and in a container, at least it's easy to reproduce the issue.