4 ms·
I thoroughly resent that I'm being forced into that workflow. I'm trying to get enough distance to tell if it's actually overkill or just being a curmodgeonly o
by pdpi 4y ago
I thoroughly resent that I'm being forced into that workflow. I'm trying to get enough distance to tell if it's actually overkill or just being a curmodgeonly old git.
- qbasic_forever 4y agoWell your alternative is to use a VM, which is a slower and clunkier container, or fight the myriad of bespoke python environment management tools so you can make one Python install work for X number of projects and all their unique dependencies.
- pdpi 4y agoI meant in general, not for Python specifically (which I don't use nearly enough for it to be a problem). On the one hand, it bothers me that software is so brittle that you need a container around it so that everything is just right. On the other hand, you can argue that containerisation is a clever way to make it all more robust.
- darepublic 4y agoTry it out you may find it makes you more productive then the old way of doing things
- nerpderp82 4y agoThe issue is with the OS and how dynamic linking works (or doesnt). The solution isn't for the maintainer of the dependencies to "try harder" or be better at what they do. The underlying system is broken and containerization is way to compartmentalize those flaws so they are less destructive. If you put everything into an Uber Container, the same problem would surface. Containers exist to solve the fragile dependency/dynamic linking problem.
- pharmakom 4y agoAgree. We don't need to use containers so often in other language stacks. this is a failure of the python ecosystem.
- nerpderp82 4y agoResent it, like resent wearing a seatbelt or eating your vegetables. It is the right thing to do even if it causes you frustration. The worst thing is if people read your statement and copy you. A container is the easiest and most correct solution here.