Deploying Django projects with conda - django

Environment management in Python projects is critical and is commonly done with venv or virtualenv. However, I am interested in deploying a Django project with conda.
The basic setup looks like the one here. Django is served using gunicorn which is controlled with supervisor.
That conda does not use folders as environments basically means that there is no isolated directory where the Django project could live (hope I got this right).
This post has a nice description of how to deploy a Python project with conda in general. For using this with supervisor I was thinking if activating a specific conda environment with installed dependencies in supervisor would suffice to create the needed results. I assume this supervisor config might look something like this:
[program:djangoapp]
command = .activate django-env; python gunicorn djangoapp.wsgi:application -b 127.0.0.1:8000
directory = /path/to/djangoapp
...
The supervisor docs say that supervisor will search the supervisord’s environment $PATH for the executable, if it's provided without an absolute path. Does this mean that the absolute path of the conda environment needs to be used here?
Long story short: Is anyone using conda for this and is it even usable the way I like to do it and if yes: How?

Related

how to use supervisor when I should running a celery in django which is in a virtualenv?

Yesterday, I deployed a Django project with nginx, uwsgi, celery, supervisor. All seemed fine.
But I have some questions come about it.
Generally saying, this time i deployed a Django project and used the local python installation, but if i must use the python in a virtual environment, what should i do ?
For example, i code some task (with django-celery) which will be used by django site to control some timing task, and the django project based python3 (the python3 environment is in a virtualenv).
So the celery should be used by python3, which is in a virtualenv, not the local python environment.
It means that if i set the command in supervisor as:
command=python ****/manage.py celery
then an error would occur.
The uwsgi has some setting about this, where I can set the path of virtualenv.
But in supervisor, I could not see some setting or some way to use the virtualenv.
Help please?
Include the path to your virtual environment in the command:
command=/path/to/venv/bin/python celery worker

is it possible to access already running virtualenv in windows

is it possible to access already running virtualenv in windows by external tools ? I need this to run cron like tasks by executing python manage.py dosometing of running instance of django. For this I thought I would setup windows task that will execute something like cmd.exe C:\django\manage.py dosometing but I dont understand how to do this if django is running inside virtualenv
Yes you can. The virtualenv is not like a virtual machine, it is not running. The virtualenv is a just a setup where you can have multiple python installations on a single machine. Each virtualenv lives in a separate directory so you can have different libraries installed, different versions of python etc. When you 'activate' the virtualenv you are just setting environment variables such as PATH which tell python programs which python executables and libraries to use.
So when people say 'Django is running in virtualenv' they just mean django is running.. and there's a virtualenv set up that is controlling which python installation Django is using.
If you look at the virtualenv documentation here: https://virtualenv.pypa.io/en/stable/userguide/ ...
It tells you that your activation script is located at:
\path\to\env\Scripts\activate
Where \path\to\env should be replaced by the actual location of your virtualenv.
So, if you are running in a command window, run the activation script first, then all your following commands will be in the virtualenv. If you're running from the scheduler etc, the easiest thing for you to do is, create a batch file which first runs the activation script, then your django command. This ensures that you'll always run in the correct virtualenv.
If you really only have one python installation, then technically the virtualenv isn't necessary.. and in that case you could edit your Windows environment variables as follows:
VIRTUAL_ENV="/path/to/your/virtualenv"
And then also, append to the end of your Path variable the path to your python and python scripts directories. On my system these are:
C:\Python27\Scripts;C:\python27\;
..and make sure there are no other python directories in your path.
If you open a powershell window and run env, it will show you the current settings of your environment variables. If you do this, run activate (in your virtualenv directory) and then run env again, comparing the Path (and other variables) between the two.. then you'll easily be able to see what activate did to your environment, and you can then add that to your Windows configuration.
Then when you run python myprogram.py it'll be using the virtualenv without activation.

Django site on Webfaction - how the flow of information works, and integrating with Pycharm remote dev

I have been learning Django in the development mode for a two months and I am up to speed with most basic aspects of python + django now. However, I was using the built-in runserver till this time
Now, I have got a Webfaction hosting account and wanted to know the following
1) Webfaction sets up the project with a certain Django version (say 1.6.4) and Python version (say 2.7) initially
The project directory (for say project MYAPP) is /<>/webapps/MYAPP
When the site is running in production mode, how does the apache server know which Python version, and which site-packages versions to use with the MYAPP source code to render the site?
I can see that the MYAPP folder has a lib/python2.7 folder, however when I am connected to SSH terminal, and do a "which python", i see :
which python
/usr/local/bin/python
so, do I take that this is the Python executable that is being used for rendering the website instead of the one in webapps/MYSITE/lib/python2.7 folder? How does the information/data flow about which programs to use during rendering the site with apache mod_wsgi work?
2) I was using a virtualenv in the development mode during testing. How do I use this on webfaction in production mode?
3) I am using Pycharm IDE. It worked well for the development mode. I can see that it has a remote interpreter configuration and a Deployment setting/option.
The python path that the remote interpreter settings tool detects automatically is the python executable at /usr/local/bin/python
Is this fine, or should I be pointing it to the more local python2.7 in the webapps/lib folder?
Thanks a lot of the answers and pls let me know if you need any supplemental info
Note to the OP: This should really be three separate questions.
1) For WebFaction, your Django app will use the Python version (and libraries, etc.) defined in:
~/webapps/<appname>/apache2/conf/httpd.conf
Specifically, you'll want to look at what is defined for WSGIPythonPath (which should mostly match up with WSGIDaemonProcess unless you modify the config and are doing something strange).
Note that which python just tells you what the default python is in your shell. This has nothing to do with the config file for the webapp.
2) You may want to expand on this as to exactly what your use case is and why the default Django webapp created by WebFaction doesn't fit your needs. But the short answer is:
Create a virtualenv on your WebFaction account.
Install Django, etc. into the virtualenv.
Edit the httpd.conf file I mentioned above to use your virtualenv instead.
I've done this with both a Django webapp made via the WebFaction control panel and via a custom mod_wsgi webapp. So it does work. Just make sure to use the right Python version when making your virtualenv.
3) I don't use PyCharm so I can't answer this (one reason why this question should be split up).

Using virtualenv with legacy Django projects

I am finally going to start using virtualenv for my Django projects on my development machine. Before I start I want to know if there are any special considerations for dealing with my existing projects. My presumed workflow is something like:
make a new virtualenv
activate the new virtualenv
Install Django in there
pip install all the packages I know I need for my existing project
copy my Django project files, app files, and git files into the project folder within the virtualenv.
Edit
6. make requirements file for deployment
This is obviously very simplified but are there any steps or considerations I am fundamentally missing? Is git going to be happy about moving? Also is it best practice to have a separate virtualenv for each Django project?
I know this is not a typical code problem, but I hope those that know more than I do can point me in the right direction.
Many thanks.
I don't see any big issue on migrating your projects and I think your 5-steps plan is correct, in particular, for steps 3/4/5 (I'd merge them), you can handle project dependencies with pip, possibly using requirement files.
Requirement files are plain text files telling to pip which packages have to be installed in your virtualenv, included your git-tracked projects which eventually can be deployed in your virtual environment as development eggs (they bring with them version control infos).
Once you have a req file, it's a matter of:
pip install -r file.req
to have all needed packages installed in your env.
As you can see from virtualenv docs, a typical req file would contain something like:
django==1.3.0
-e git://git.myproject.org/MyProject.git#egg=MyProject
I usually keep each project in its own virtualenv, so I can deploy it to the production server the same way I do for local development.

Django application installation

I'm still busy with my Django learning adventure. In another post I asked about how to structure a Django project and applications using buildout. In the details of doing this arose another issue, simply installing 3rd party Django applications using either easy_install or setup.py. My question is, where should you install a Django application? If looking at Django documentation, one would think to put a Django application inside the project folder. But if your Django application is an egg (a mystifying term in my opinion) and you use easy_install without option '-b' (build-directory) the application will be installed into your current python site-packages directory. Using option '-b' will put a copy of the application in your directory, but still will install it in your current site-packages directory. Then there are other options like --install-dir and prefix. Also how should installation happen when using setup.py which have similar options as buid-directory, install-dir, and prefix?
Is there a 'good practice' standard for installing 3rd party Django applications into a Django project?
Thank a lot,
Todd
They usually aren't installed directly into the project. They're either installed into the system's site-packages/ directory, or in the virtualenv's site-packages/ directory, or in some other well-defined place that the sysadmin has set for this purpose.
This is where virtualenv comes into its own. It basically enables a project-specific site_packages directory, where you can install all the third-party applications that relate to your project. I'd definitely recommend it.
Follow these steps :
change the path according to your local setup
C:\Python27\Lib\site-packages>python pip install django
Create Project
Go to folder where you want to create a project
E:\djangoProject>C:\Python27\Lib\site-packages\django\bin\django-admin.py startproject myproject
python manage.py help is used to list all the commands
Manage.py  This file is kind of your project local django-admin for interacting with your project via command line (start the development server, sync db...)
Run Server
E:\djangoProject\myproject>python manage.py runserver
Create App
E:\djangoProject\myproject>python manage.py startapp myapp
Go to myproject  settings.py and register your app “myapp” created under INSTALLED_APPS
Migrate DB  E:\djangoProject\myproject>python manage.py migrate
Migrate will create necessary tables or collections depending on your db type, necessary for the admin interface to run