I was used VirtualBox manual setups with virtualenvs inside them to run Django projects on my local machine. Recently I discovered Vagrant and decided to switch to it, because it seems very easy and useful.
But I can not figure - do I need still use virtualenv Vagrant VM, is it encouraged practice or forbidden?
There are also workflow tools that simplify this process, such as Pipenv and Poetry. They create virtual environments for you without perception and then install dependencies into them. They are used by a wide range of users.
These are almost completely interchangeable, the difference being that virtualenv supports older python versions and has a few more minor unique features, while venv is in the standard library.
virtualenv allows you to avoid installing Python packages globally by making an isolated python environment. That means it will install packages just in your desire project folder.
The simplest way to do this is via Port Forwarding, to connect and relay the data to be sent from a port of our host machine to a port of our virtual machine. Then, to take this new setting use vagrant up (or vagrant reload if the vm vagrant is already picked up).
As Devin stated, it is not necessary to use virtualenv
when you deploy to a vagrant machine as long as you are the sole user of the machine. However, I would still enable the use of a virtualenv
, setup.py, etc. even if you do not use it for development or deployment.
In my (not so) humble opinion, any Python project should:
virtualenv
directories.Include a Makefile with the following targets:
virtualenv
or pyvenv
pip
and the requirements.txt filesetup.py develop
using the virtual environmentsetup.py test
The idea is to keep the Makefile as simple as possible. The dependencies should be set up so that you can clone the repository (or extract the source tarball) and run make test
. It should create a virtual environment, install the requirements, and run the unit tests.
You can also include a Vagrantfile and a vagrant target in the Makefile that runs vagrant up. Add a vagrant destroy
to the maintainer-clean target while you are at it.
This makes your project usable by anyone that is using vagrant or developing without it. If (when) you need to use deploy alongside another project in a vagrant or physical environment, including a clean setup.py and a Vagrantfile that describes your minimal environment makes it simple to install into a virtual environment or a shared vagrant machine.
If you run one vagrant VM per project, then there is no direct reason to use virtualenv.
If other contributors do not use vagrant, but do use virtualenv, then you might want to use it and support it to make their lives easier.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With