I am newbie using VirtualEnv and recently try to create one using PyCharm. During the process, PyCharm ask me to specify the project location, application name and VirtualEnv name and location. My doubt is, after I specify the name and location of the VirtualEnv the location of the Django project files must be inside the VirtualEnv? or it's possible to have the VirtualEnv files in a different location than the Django project files?
Maybe I am not understanding the purpose of the VirtualEnv. Perhaps, VirtualEnv it's just a list of the dependencies of my project, Python version, Django version, Pip version, Jinja2 version and all other required files, but not necessarily the Django application files (the website that is being developed).
Thanks in advance.
Ya, I think you misunderstand what virtualenv does:
https://virtualenv.pypa.io/en/latest/
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.
Your project files don't need to be (and shouldn't be) where the virtualenv files are.
virtualenv installs your app's python dependancies in a folder for the specific virtualenv that is being used.
Let's say you are not using virtualenv, the dependencies would be installed into into the site-packages folder for your system. The dependancies aren't installed in your project directory and your project directory isn't in your system's site-packages directory.
Using virtualenv doesn't change that, it just changes where the dependencies are installed.
virtualenv is not just a list of dependencies! It actually has all the modules under its umbrella. Think of a virtualenv as a space which isolates all the packages used by your project from the rest of the other packages that were installed previously or at a later time.Yes, there is an option to have the virtualenv make use of packages that are "outside" of the environment but that's just an option.
The main purpose of having an virtualenv is to enable the user to use packages versions of his choice and keep them isolated from the rest of the space. Usually, the list of packages belonging to a specific virtualenv are captured into a file, requirements.txt. If you want to run the project on a different machine or share it with someone, having requirements.txt will make it easy to recreate the environment via pip install -r requirement.txt from within virtualenv
Related
My question is do i have to install django every single time in my virtual environment in order to run my python files? and is this taking up bunch of space on my machine? My project also uses "matplotlib" and every virtual environment i create it also asks me to import the matplotlib module too. its getting annoying. do i have to do this every time?
Im new to Django. I wanted to run some python files in django but they weren't working, so after some research i found out i needed to run my pycharm project in a virtual environment in order to run these python files.
my folders look like this pycharmProjects -> my project
I enter pycharmProjects and I set up virtual environment using "pienv shell". Then i run "python3 manage.py runserver". It turns out i must install django in the virtual environment before the files run.
Short answer is no, you don't have to use a virtual environment at all and can install your dependancies globally instead. However you will soon find that it will cause a lot of issues. The main reason you would create a virtual environment is to give control of your dependancies and prevent bugs that could be caused because of them having their wires crossed between projects.
Short answer yes.
If you create a virualenv you have to install all packages, that your program needs.
Long answer:
You could install django system wide and then create a virtualenv with the option
--system-site-packages then django would be used from your globally installed python.
(Or you install everything just in your global python, put I personally don't think this is good practice)
If you work with many different projects I think you will avoid a lot of trouble if you use one virtualenv per project.
Trouble meaning that one project breaks, because one pip install for another project changed the version of one package and one project can't handle the newer version.
I would recommend to create a requirements.txt file for each project, that lists the dependencies then you can create the virtualenv with following command
pip install -r requirements.txt
if you have requirement.txt files, then you can create virtualenvs rather quickly if going back to an old project and you can delete the virtualenvs whenever you run out of disk space. If you want to be an the safe side, type pip freeze > pipfreeze.txt prior to deleting the virtualenv and use pip install -r pipfreeze.txt if you want to create one with the same modules and the same versions.
You also might want to look at direnv or autoenv if working on a linux like system.
This will automatically switch to the required virtualenv when changing to a project's working directory.
I'm a huge beginner so I'm not very informed about how packages really work. I know that you should create a virtualenv in your project folder to avoid version conflicts etc, and you're not supposed to put your actual project files in the virtual env. So if your project files are in your project directory on the same level as the virtualenv, can your project files "access" the things installed in the virtualenv? Can files outside of your directory access packages in your virtual env?
Yes, it all depends on the context. Your virtualenv can exist anywhere, be it in your project directory, or somewhere else.
When you want to use the virtualenv, you just have to call source command on it. Then whatever python command you execute on whichever file, will have access to the virtualenv. For example, if you store your virtualenv in /home/user/project/virtualenv, then you would do
source /home/user/project/virtualenv/bin/activate
Then whatever you with the python, it would be the version installed in virtualenv.
You can double check if you're using the global python or the virtualenv python by doing which python. It will either point to the global python path which is usually under /usr/bin/python or /home/user/project/virtualenv/bin/python.
So normally, you first do the source command, then you can do pip install on whatever packages you need already. It will be installed in the virtualenv and it will not conflict with other projects.
I downloaded a Python project and it contains both a virtual environment and a requirements.txt file. Why would you need both? As far as I know, virtual environments already contain the required modules. Any idea when and why this combination would be useful?
While it is technically possible I don't find any good reason to that. Having both is confusing because it is not clear which one is the "master". And you have to (or not?) worry about consistency between installed packages and requirements.txt file.
Also venv and installed packages in many cases depend on the underlying OS, they have binaries, different layout, etc. It is generally advised to write os-independent code.
All in all, I would stick to requirements.txt file and remove any venv folder from the project's repo.
You can't distribute the virtualenv directory with your project because the contents may vary depending on the target operating system and the version of the operating system. Specifically, a virtualenv that includes libraries with compiled components installed on Ubuntu 14.04 will differ from the equivalent virtualenv installed on Ubuntu 16.04.
Instead, you should distribute your requirements.txt file (just a convention, you could use any file name you want) so the end-user will be able to recreate a virtualenv on his machine.
I'm currently hosting with a dreamhost shared VPS. I do not have sudo rights. I want to install django packages but I cannot to /usr/local/lib/python2.7/dist-packages/ because python is root access only. I have setup a directory in my user directory also called dist-packages to which I have copied all my packages to. I want to use the packages in the dist-packages directory I created to build my django app. Is possible to use my packages? I'm looking for a work around. I do have virtual python env installed, is there a way to use it maybe?
Python 2.7
Django 1.9
My current setup
/home/myuser/mydomain.com/
env/
myApp/
passenger_wsgi.py
public/
How do I setup the env?
You should be using virtualenv for sure(I'm surprised that you are still looking for a work around). It's really inconvenient to use default python for everything. virtualenv will create an isolated python directory of your choice and install everything in there. When you want to use it, just "activate" it then you are automagically in that python environment.
It's almost trivial to learn how to create one, you can even create as many as you like, each with different packages installed. Check their doc for more details.
So, I want to start using virtualenv this year. I like the no-site-packages option, that is nice. However I was wondering how to install certain packages into each virtualenv. For example, lets say I want to install django into each virtualenv... is this possible, and if so, how? Does buildout address this?
Well it's not so much django, more like the django applications... I dont mind installing a version of django into each virtualenv... i was just wondering if there was some intermediate option to 'no-site-packages'
I know where you're coming from with the no-sites-option. I want to use pip freeze to generate requirements lists and don't want a lot of extra cruft in site-packages. I also need to use multiple versions of django as I have legacy projects I haven't upgraded (some old svn checkouts (pre1.0), some 1.0, and some new svn checkouts). Installing Django in the global site-packages isn't really an option.
Instead I have a django folder with releases and a couple of different svn versions and just symlink to the appropriate version in the local site-packages. For ease of use I link to the local site-packages at the same level as the environment and then link in the appropriate django directory and any other "system" style packages I need (usually just PIL). So:
$ virtualenv pyenv
$ ln -s ./pyenv/lib/python2.5/site-packages ./installed
$ ln -s /usr/lib/python2.5/site-packages/PIL ./installed
$ ln -s /opt/django/django1.0svn/trunk/django ./installed
Now the following works:
$ source pyenv/bin/activate
$ python
> import django
> import PIL
If you want django to be installed on EACH virtualenv, you might as well install it in the site-packages directory? Just a thought.
I'd suggest using virtualenv's bootstrapping support. This allows you to execute arbitrary Python after the virtualenv is created, such as installing new packages.
The other option (one I've used) is to easy_install Django after you've created the virtual environment. This is easily scripted. The penalty you pay is waiting for Django installation in each of your virtual environments.
I'm with Toby, though: Unless there's a compelling reason why you have to have a separate copy of Django in each virtual environment, you should just consider installing it in your main Python area, and allowing each virtual environment to use it from there.
I want to check out this project:
http://www.stereoplex.com/two-voices/fez-djangoskel-django-projects-and-apps-as-eggs
Might be my answer....