3 ms·

Can someone explain the benefit of using a separate env for each project? Why not just use the default env for all your projects? Does it have something to do w

Can someone explain the benefit of using a separate env for each project? Why not just use the default env for all your projects? Does it have something to do with the ops part of devops?

stevula 7y ago
You might need to make sure you’re using the same version of Python and project dependencies as you have deployed somewhere. Those versions might be different than your system version. Keeping your project dependencies isolated also encourages you to document your dependencies (e.g. in requirements.txt), which is essential for reproducibility. If you have every package from every project installed globally then you tend to end up having issues when you or someone else tries to install a project in a different environment (the classic “I don’t know what’s wrong on your machine but it works fine on my mine”).
amanzi 7y ago
Nothing to do with DevOps, more to do with keeping your different projects separate with their own dependencies. That way, if you need to move the package to another machine, you can just do a `pip freeze` to document which packages you need, then `pip install` them on the new machine. If you just want a sandbox area where you'll be developing lots of little scripts and bits and pieces, there's nothing stopping you from having a single environment that you keep adding to as you go. You just miss out on the portability aspects mentioned above and potentially risk getting conflicts over time as the number of packages you install grows and grows.
prepend 7y ago
You might need to use different versions of python. That will require different versions of some packages. And you need to prevent conflicts.
m4r35n357 7y ago
The bigger the venv gets, the more likely you are to get version clashes - unless all your projects can use the same version of each dependency. Even then, it will tend to grow without bound.

Can someone explain the benefit of using a separate env for each project? Why not just use the default env for all your projects? Does it have something to do with the ops part of devops?

stevula 7y ago

You might need to make sure you’re using the same version of Python and project dependencies as you have deployed somewhere. Those versions might be different than your system version. Keeping your project dependencies isolated also encourages you to document your dependencies (e.g. in requirements.txt), which is essential for reproducibility. If you have every package from every project installed globally then you tend to end up having issues when you or someone else tries to install a project in a different environment (the classic “I don’t know what’s wrong on your machine but it works fine on my mine”).

amanzi 7y ago

Nothing to do with DevOps, more to do with keeping your different projects separate with their own dependencies. That way, if you need to move the package to another machine, you can just do a `pip freeze` to document which packages you need, then `pip install` them on the new machine. If you just want a sandbox area where you'll be developing lots of little scripts and bits and pieces, there's nothing stopping you from having a single environment that you keep adding to as you go. You just miss out on the portability aspects mentioned above and potentially risk getting conflicts over time as the number of packages you install grows and grows.

prepend 7y ago

You might need to use different versions of python. That will require different versions of some packages. And you need to prevent conflicts.

m4r35n357 7y ago

The bigger the venv gets, the more likely you are to get version clashes - unless all your projects can use the same version of each dependency. Even then, it will tend to grow without bound.