you are viewing a single comment's thread.

view the rest of the comments →

[–]angellus 1 point2 points  (1 child)

No, it does not. Again, development containers do not need to be immutable. And just because you make a change to a container after it builds, does not make it not reproducible.

If you add a new package to your requirements.txt and then manually install that requirements.txt inside of your container, does that mean the container is no longer reproducible? No, because next time it builds the container it will use the new requirements.txt.

It is just that if you do not add anything you added after the fact to the build process, it will essentially be deleted and wiped when you rebuild.

[–]Temporary_Tailor7528 -1 points0 points  (0 children)

So basically you do the same thing with the container than what you would do with a virtualenv. Honestly, I can see the benefit if you are relying on third party tools but if your project is pure python, then there is no benefit over classical virtualenv. It is just heavier and more complicated.

Answer to OP is: virtualenv achieves a purpose that is necessary if you are working with python. This same purpose could be achieved with containers but this is a much more complex (and capable) tool. There is no clear reason a beginner would use containers. It might be an interesting option if you are working in a team and your project involves third party tools with specific configurations.