4 ms·
Do you just use one environment for every project? That gets messy. What if you want to setup a new machine? Or a new employee's machine? Etc.. It isn't only
by odonnellryan 9y ago
Do you just use one environment for every project?
That gets messy. What if you want to setup a new machine? Or a new employee's machine? Etc..
It isn't only about conflicting packages.
- amenod 9y agoYes - but then again, I don't have that many projects and I tend to use the same libraries across them anyway. Installing on another machine is just a matter of pip install -r requirements.txt, if it's for a dev. other wise it's just a docker run .... I do know that most Python devs use virtualenv, I just never understood what all the fuss is about. Of course I don't mind if the others in team use it, I just never saw the appeal so I'm curious what other peoples' reasons are. Maybe I don't see the need because I came to Python quite late, a little before Docker came around, and we were early adopters for Docker. So we solved testing and production with Docker (and thus never needed to support multiple Python versions in parallel). It's really one of those small mysteries I don't understand. :)
- odonnellryan 9y agoYeah I understand what you mean. I have around ~12 projects, for different clients, that are just recent enough that I might need to access the environments. If that was one environment (forget some of them being stuck on 2.x) the number of damn dependencies would be monstrous! When I need to bring a partner onto the project, I can't give them a requirements file that's 5x what it should be! > I just never understood what all the fuss is about. It's to keep environments clean + easy to maintain. Virtual is probably a bad word for it. It isn't like Docker or a VM. I don't think too many Python projects that are not libraries support many versions, that isn't the point of virtualenv or conda anyway.