We are considering using Django for an application which can be seen mostly as a desktop application. That is, it is not to be installed on our servers, but directly on our customer's laptops (but still accessed through their browser on localhost.)
Whilst it is OK to require Python to be installed, it is not to require to install Django, or other dependencies.
It would probably run using the internal runserver. And most likely not use SQL (or only SQLite if necessary.)
Is it possible to "package" the application with Django and all dependencies? What are the options here? Ideally, the install guide would read:
install Python, if not done yet
download and unzip our application archive
go to that dir and execute python3 manage.py runserver
Note I: The goal is NOT to package a publicly available website as an app.
Note II: The only related questions I have found are several years old (10 and 7 years old resp.)
Note III: The customers use Linux, Mac and Windows.
Related
I'm considering building app with Django for only one user that would run application locally on windows. I read about containerizing Django apps, but it's new for me.
My goal is to run Django server on one click like a standard windows app and connect to it on localhost and interact with web browser. It is even possible?
It is possible, but this may not be the best solution. If you want to release a Django app that can be installed on your client computer, you usually need to ensure all the dependencies are shipped with the app.
Containerising your application means it will depends on Docker runtime (or any container system you use). You will have to setup Docker with your app, or ensure your client has Docker on his machine to run it. If the destination machine runs Windows or macOS, you will need to setup docker-desktop which may be more complicated than standard Docker runtime (linux only).
But if you decide to ship your app without containerising it, it will only depends on a Python interpreter and some dependencies (Django, dateutil, etc.). In such case, using python tools like virtualenv, you may prepare a ready-to-run application by creating the venv and installing dependencies at "build time". Then, with a proper setup (MSI for Windows or DMG for macOS), you may be able to distribute the final application so the client can install and run it without any additional step (you do all the hard job yourself).
Django app can be convert into .exe but it wont work as local server while click .exe because runserver command and some of django service wont support on this way as per my experiment.
Hopefully this isn't too stupid of a question, concerning the use of pipenv for the same Django project on different computer systems. The scenario is that I'm using pipenv with a test Django project on one laptop, everything works fine, using VS Code and it's using the proper pipenv environment for the Python environment within VS Code.
The project however is within Dropbox so when I'm using a different laptop, which I do sometimes, one is my work laptop the other is my personal one at home, I can work on the same project wherever I left off. So you can probably deduce the issue I'm having.
I'm using pipenv environment A on my work laptop for the Django project. But when I open the project in VS Code on my personal laptop at home I have to keep specifying the proper pipenv environment to use, which obviously is different than the one on my work laptop.
Maybe I shouldn't be working this way and should just work on one laptop for the project, but I imagine others have done the same with similar setups before.
Is there a "proper" way to do this, using different pipenv environments on different machines for the same Django project? Should I copy over the pipenv environment to each machine as well? Or am I missing something really simple here?
First, use version control. (git is the defacto standard these days and there are plenty of services to choose from)
For using pipenv, you want to keep your Pipfile and Pipfile.lock in your repository (these are the only files you should be copying related to your environment from system to system).
The local environment is then built on each machine where it is needed by using pipenv sync or pipenv sync --dev (to install dev specific requirements).
So the related virtualenv will be created on each system in which you are developing your project.
The question is in the title.
I need to deploy a Django application in a local network (i still don't know how to do but i suppose it's quite easy) but i still need to develop it. My question is how to do to allow users to use the application while i'm still developing it ?
Is it a solution to keep to versions of the application, one deployed and one in development ? In this way, I can replace the application deployed by the newly developed one when I finish coding it.
Another question concerns the database, can I still modify the database if I just add new models without touching existing ones ?
Thank you in advance,
This is a good blog entry that covers deploying Django using Heroku. I'll give you a quick rundown of what makes all the different technologies important:
Git
Git, or any other version control system, is certainly not required. Why it lends itself to deploying Django projects is that your usually distributing your application by source, i.e. your not compiling it or packaging it as an egg. Usually you'll organize your Git repository as such that updating your application on the server only requires you to do a checkout of the latest sources--nothing else.
virtualenv and pip
This, again, is not a strict requirement, but I'd strongly suggest you take the time to familiarize yourself with virtualenv and pip if you already haven't done so, since it's going to make deploying your Python applications across different runtime environments, local or remote, a breeze.
Basically, your project will need to have at least Django and Gunicorn available on the Python path, possibly even a database driver. What that means is that every time you try to deploy your application somewhere you'll have to install Python and do the easy_install dance all over.
virtualenv will redistribute a Python installation, which in turn means that the new Python instance will, by default, have it's very own Python path configuration relative to the installation. pip is like easy_install on steroids, since it supports checking out Python dependencies directly from code repositories and supports a requirements file format with which you can install and configure all of your dependencies in one fell swoop.
With virtualenv and pip, all you'd need to do is have a simple text file with all your dependencies that can be parsed with pip and an installed Python distribution on the machine. From there you just do git checkout repo /app/path; easy_install virtualenv; virtualenv /app/path; ./app/path/scripts/activate; pip install -r /app/path/requirements.txt. Voila, Gunicorn, Django and all other dependencies are then installed and available immediately. When you run the Gunicorn Django script with the Python instance in /app/path/scripts, then the script will immediately have access to the Gunicorn sources and it will be able to locate your Django project which will have access to Django and other dependencies as well.
Gunicorn
This is the actual Python application that will manage your Django instance and provide an HTTP interface that exposes it to HTTP clients. It'll start several worker processes which will all be distinct Python virtual machines loaded with the sources of your application and it's dependencies. The main Gunicorn process will in turn take charge of managing which worker processes manage which requests for maximum throughput.
The basic principle of wiring Nginx and Gunicorn
The most important thing to observe is that Nginx and Gunicorn are separate processes that you manage independently.
The Nginx Web server will be publicly exposed, i.e. it will be directly accessible over the internet. For requests to static media, such as actual images, CSS stylesheets, JavaScript sources and PDF files accessible via the filesystem, Nginx will take charge of returning them in the response body to HTTP clients if you configure it to look for files on the path where you configured your project to collect static media.
Any other request should be proxied to your Gunicorn instance. It will be configured to listen to HTTP requests on a certain port on the loopback interface, so you'll using Nginx as a revers proxy to http://127.0.0.1:8080 for requests to your Django instance.
This is the basic rundown for deploying your Django projects into production that should satisfy the needs of 95% Django projects running out there. While I did reference Nginx and Gunicorn, it's the usual approach when it comes to setting up any Web server to act as a reverse-proxy to a Python WSGI server.
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).
We are currently testing Django on a live server using Windows 2008 webserver and IIS7. To run Django projects on IIS we use Helicon Zoo (Python hosting package with Django).
The plan is to host multiple clients on that webserver and we would like to use virtualenv, so we can upgrade python packages for specific clients, without affecting the others.
The specific question is; when we have several virtualenvs on the server, how do we set up the different Django sites under IIS to use a specific virtualenv?
Thanks in advance for your time and answers,
Erik
It is not quite clear to me whether you need different versions of Python or different versions of modules, used in the application.
To have different python versions you can install another python manually, then go to applicationHost.config file, find . Engines declarations will be listed there. Create a copy of "python.2.7.wsgi" and edit the copy, name it like "python.2.5.wsgi" and change executable name path. This is how you can declare more engines with different versions and settings. Here you can find more information: Helicon Zoo Module documentation
As for Python modules, it is supposed that modules are installed locally in the client's web site in \python_modules\ directory. When you create new Django application using Helicon Zoo, it is configured to use isolated environment by default, you only need to learn how to use it right and tell your clients to follow guidelines. You can find the information in this article: Running Django on Windows (with performance tests)