We Keep Coding

How to set up a local dev environment for Django

Python web development newbie question here. I'm coming from PHP/Laravel and there you have Homestead which is a pre-configured Vagrant box for local development. In a so-called Homestead file, you configure everything such as webserver, database or PHP version. Are there any similar pre-configured dev environments for Django?
I already googled and there don't seem to be any official or widely-used Vagrant boxes for Django. The official Django tutorial even tells you how to install and set up Apache and your preferred database. This is a lot of work everytime you want to create a new Django project, especially if those projects run in different production environments. All the other tutorials I've found just explain how you set up virtual environments with venv or the like. But that doesn't seem to be sufficient to me. What you obviously want is a dev environment that is as close as possible to your production environment, so you need some kind of virtual machines.
I'm a little bit confused right now. Do you just grab some plain Ubuntu (or any other OS) Vagrant box and install everything yourself? Don't you use Vagrant at all but something else? Did I miss something and the Python web development workflow is completely different?

The typical local development in Django just uses the builtin web server and an SQLite database. The steps to get that up and running are:
Ensure you have the desired version of Python installed.
Create a virtual env to isolate libraries needed for your project from the rest of the system (this is optional by highly recommended, I'd actually recommend using Poetry).
Install Django, probably via pip.
Run manage.py runserver (and migrate the database and set up a superuser, yada yada).
That's pretty much it and sufficient for local development. What you need to be aware of is that some differences exist between SQLite and Postgres, MySQL etc., and if you hit the spots where the difference is important, you'll want to set up your targeted database as well to develop directly against it. That can probably happen in a Docker container if that makes sense for you. But there's little reason to put Django into a container during development, unless your project is especially complex and requires simulating certain conditions which the builtin server somehow can't.

Does this help?
$ python3 -m venv my_env # create your virtual environment
$ source my_env/bin/activate # Any package you install will be inside this environment
$ pip install -r requirements.txt # can also install packages indivdually
$ deactivate # get out of the isolated environment
Here's the doc

Best practice for package install on django server

So I'm setting up a server by myself. Now I ran into lots of different ways where to install the packages.
I am thinking of the core packages like nginx, gunicorn, python3, postgresql and so on.
I learned that setting up a VENV (virtual environment) is a good thing so I can have several projects running with different versions on packages.
But it's a bit confusing wich ones are not going to be inside the VENV.
Some install postgreSQL outside the VENV, but psycopg2 inside. Some the gunicorn inside VENV. and so on.
Are there any best practices or rules that are better safe to follow?
For info. I'm setting up a Ubuntu server 16.04 with Nginx, gunicorn. PostgreSQL, psycopg2, python3

This what I use for my applications, it's working but maybe there are better options.
Nginx, PostgreSQL, python3, supervisor installed as system packages
Using virtualenv for each of the applications I run inside one server
and I install there: gunicorn, psycopg2 and all other requirements
for Django project (Most of the time it's listed inside
requirements.txt file)
Using supervisor to run gunicorn and Celery(When needed)
If you want to make some server installation automation you can use Ansible, it's not that complex and interface well with Python/Django with plenty of code examples. But it's better that you start doing things on your own at first to know and understand what you're doing.
Good luck

#Mounir's answer is pretty solid- but I wanted to tag on another piece of advice- using playbooks from Ansible Galaxy is also another option. Existing playbooks already exist for lots of usecases (including Django) and they take into account many of these best practices. I am not saying that all playbooks on Galaxy are good- but some are, and by virtue of being open source, they are frequently patched and updated.

Parallel Python install on Media Temple DV server

Plesk on the MediaTemple DV servers uses Python 2.4 for stuff, so the 2.4 install can't be replaced but someone recommended installing a separate python 2.7 install since my app runs on that. I'm new to the whole server thing, so this is new territory. My sense is that I can create a new directory for the source files and use SSH to download the files to said directory and then cd into it and install python 2.7. Then I have to figure out how to make sure Apache knows to use Python 2.7 to run the django app in question. Does this sound correct?

Unless you can make a system wide change to your python installation, you would have to run Apache, python and Django in the same virtual environment. If it is not possible, use gunicorn (instead of apache) to run the Django app in a virtualenv (in a port different from Apache's). If this app runs in a subdomain, you should consider hosting the Django app in a PAAS (Heroku, Google App Engine, etc.) which allow you to easily switch running environments.

Never mind, sorted it. the important thing seemed to be to edit the etc/ld.so.conf by adding usr/local/lib, then running sbin/ldconfig, which then makes ld.so.conf look like:
include ld.so.conf.d/*.conf
/usr/local/lib
Donwload and then compile Python
and use make && make altinstall.

Easiest way to share work between backend and front end

Hey everyone,
I am expanding my team and I have recently added an additional front end engineer on my site. I am currently using django to run my site but my site is using a lot of plugins, namely: django-celery, django-mailer, django-notification, and django-socialregistration.
Let me describe my situation:
He is using Mac OS X, and I have no experience in installing stuff on mac os X or configuration on that platform
I believe that getting my backend to run on his computer might be somewhat troublesome, i.e. I have to install a bunch of plugins (which are not available on pip or easy_install as they are the latest version) and I have also made heavy modification to django-socialregistration which I am currently using by symlinking to the modified code in my repos in my python path
I tried to look into solutions like pip and easy_install but I have not been able to get them to install code from github
I think the easiest way is to get my backend working on his computer and then he just commiting to the repos. Any ideas how I can make this easy?

Another, free option, is to use VirtualBox. I would recommend installing the same OS on it as your production server. Then, he's developing in the same environment as the live site, and can just check into the repo the same as you. Hey, you may want to do the same on your end--then both of your environments are the same and also the same as the live site.

Get him to set up a virtual machine on his Mac, using VMWare Fusion or Parallels, running the same operating system that you currently use for your back end. If he prefers developing using Mac tools he can do still that by sharing his local changes to the virtual machine via a shared directory.

An alternative, if that's possible, would be to set up a testing/development environment on a machine with an OS you're familiar with, then install something like Dropbox on his local machine where he can develop the frontend code, and install Dropbox on that other environment with the backend components. Dropbox would sync his local changes to that testing environment for him to run the code on.
That way, he would be able to use that environment to test his code, you wouldn't need to set up a backend on his machine (or keep it up to date) and you'd still be getting the same functionality.
Again, if that's an option.

Package a django project and its dependencies for a standalone "product"

I've made a small little "application" utilizing Django as a framework. This is an application that is not ment to be deployed to a server but run locally on a machine. Thus the runserver.py works just nice.
I, as an developer is comfortable with fireing up the terminal, running python manage.py runserver and using it.
But I have some Mac OS X and Windows friends wanting to use my application, and they dont have virtualenv, git or anything else.
Is there a way I can package this to be a standalone product? Of course it would depend on Python being installed on the system, but it is possbile to package the virtualenv — with django and everything, and just copy it to another system and make it work?
And maybe even run the runserver in some kind a deamon mode?

Use setuptools and easy_install.
Here's an introductory article.

Yes, you can package it. Django may not be the easiest to do this with, but the principles are the same for other frameworks. You need to make an installer that installs everything you need. And that installer needs to be different for different platforms. such as Windows, Ubuntu, OS X etc. That also means that the answer is significantly different for each platform, and only half of the answer is dependning on Django. :-(
This kinda sucks, but that's life, currently. There is no nice platform independent way to install software for end users.

I also haven't found the perfect solution for this yet.
My current approach is to provide a docker image because that's really easy to use for everyone. This includes an alpine base image because it's tiny and python + django and the app itself. You can also include a webserver like nginx and an app server like uwsgi or gunicorn and expose a port for it.
So in the end your user would just run the container and access the web app under http://localhost:9000/ or something like this.
This is really handy and also my preferred way of trying out some app I've found.
The "proper" way would be do build a package for every OS and distribution you are targeting and a simple zip bundle so people can also install the app manually.
To build the packages I suggest using fpm. It takes most of the pain of doing the packaging with their native tools away. The packages would then depend on a proper application server like uwsgi or gunicorn.
So in the end you could then install it like apt install your-package and it would depend on python-django, uwsgi etc.
For the location and where to put all the files in the package every distribution has their own way of doing it. I prefer putting everything under /usr/share/webapps/myapp/ and having the config under /etc/myapp/config.py or something like that.
For Windows and macOS there are solutions like PyInstaller. I haven't used it yet for a django app but it should do the job. You should include a app server like uwsgi in there too.
In generel you don't want to run the django dev server in a production environment. So keep that in mind when packaging.
I hope that helps a bit.

There are several ways of doing this. I think you are looking more for build tools (which includes packaging) rather than just a Python solution. Here are a couple that I've used in the past:
zc.buildout: Used to build and deploy Python modules and applications, but is also able to work with other languages with a little massaging. Easy to use (for a build tool).
make: The software build classic. Works with practically all languages but a little archaic and hard to learn for a first timer.

The new snap package manager for Linux should suit the task perfectly. It provides all the solutions that were quite a pain for Python apps so far (dependencies, interpreter etc) and at the same time avoiding the complexity of Docker.

These days Docker is probably a good answer
User needs to install Docker first, but it runs on Windows and OSX as well as Linux.
Your Dockerfile takes care of installing all the dependencies and then runs the devserver (or you could even run a proper webserver in the container)