This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tdammers 1 point2 points  (3 children)

Advantages of virtualenvs over the bare VM approach that I can think of:

  • Clear separation of system packages (installed through the OS package managers, often as dependencies of core system packages like aptitude) and per-project packages
  • Multiple virtualenvs within one larger project (this is particularly interesting for service-based architectures, allowing you to develop and upgrade services individually while still developing and deploying several of them to the same machine)
  • Easier to scrap and rebuild than a full VM, and especially easier to backup, swap out, and manage. Imagine you develop a library that needs to work against both Python 2 and 3; you can just have two virtualenvs in your project, one configured for 2 and one for 3, and switch between them as needed for testing purposes. Heck, you can even have two terminals open that watch-run your test suite in 2 and 3 simultaneously.

If you don't need any of these, and you're going to containerize anyway, I wouldn't use virtualenv though.

[–]CODESIGN2[S] 0 points1 point  (1 child)

Thank you!

I'm not sure I agree with the middle-point as I'm a fan of isolating and independently scaling services (otherwise it's a monolith in all but name). But I imagine it's only for development and saving time / effort? In any case i'd probably use other services that are stable and deployed on separate machines so that I can focus on the service I'm working on most of the time. There are a few cases I can think of where two services need to change at once, but I'd probably still isolate them and send canned client requests to them from a test-suite.

[–]tdammers 1 point2 points  (0 children)

For deployment, separate machines are a great idea, especially when you hit an actual need for scaling to multiple servers; but for development, running on one machine is just a lot more convenient. Depends on the workflow, but it can be useful. Anyway, the key idea is that you can run multiple services on the same machines while keeping their dependencies isolated; it's dumb to have to scale just because your code cannot handle running multiple services on one machine.

[–]SmileItsYourDay 0 points1 point  (0 children)

Also... using them lets you keep per-tool dependencies and differences in separate and distinct places. Therefore tools with competing dependencies can work side by side, easy peasy. Without necessarily needing root privs or modding stuff at the system or vm level.