Anything you are going to deploy to a server, you should use docker unless you have a really good reason not to. It's a better alternative to having a lot of custom scripts that install whatever on a server and it will just run on most server platforms. Something a lot of javascript, ruby, and python hackers always struggled with is the notion that system administrators generally don't like having to deal with stuff that just craps all over the filesystem that requires root permissions; dumps all over the place in /usr, /lib, etc. Things like virtualenv really have no business being on a server: they are development tools intended for developers on their workstations. Having any kind of custom install procedures for software on servers is just not a thing these days.
If you are using docker anyway, using docker build to build, package and run your application locally also makes a lot of sense. All it requires is adding a Dockerfile to your repo. It's really easy to set up and you document exactly what your application needs to run as a side effect. You can pick whatever python version you need, whatever libraries, binaries, etc. need to be there, etc. And if you then still want to run virtualenv or similar locally you still can.
That makes sense! I have worked on servers in the past and I can see how it would be a benefit to use Docker in that case. Plus, like you mentioned, it helps in picking the exact version of Python along with all the libraries and such that are needed.
How do you square this with text editors that expect the packages to be available locally and give linting errors (not to mention don't give hints as to how to use the API) if your packages are all sitting in a running docker container?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Anything you are going to deploy to a server, you should use docker unless you have a really good reason not to. It's a better alternative to having a lot of custom scripts that install whatever on a server and it will just run on most server platforms. Something a lot of javascript, ruby, and python hackers always struggled with is the notion that system administrators generally don't like having to deal with stuff that just craps all over the filesystem that requires root permissions; dumps all over the place in /usr, /lib, etc. Things like virtualenv really have no business being on a server: they are development tools intended for developers on their workstations. Having any kind of custom install procedures for software on servers is just not a thing these days.
If you are using docker anyway, using docker build to build, package and run your application locally also makes a lot of sense. All it requires is adding a Dockerfile to your repo. It's really easy to set up and you document exactly what your application needs to run as a side effect. You can pick whatever python version you need, whatever libraries, binaries, etc. need to be there, etc. And if you then still want to run virtualenv or similar locally you still can.
That makes sense! I have worked on servers in the past and I can see how it would be a benefit to use Docker in that case. Plus, like you mentioned, it helps in picking the exact version of Python along with all the libraries and such that are needed.
How do you square this with text editors that expect the packages to be available locally and give linting errors (not to mention don't give hints as to how to use the API) if your packages are all sitting in a running docker container?