Creating a redistributable django app - django

In Java world, a common way to distribute a web app is to package it along with Apache Tomcat.
What is the appropriate way to achieve something like that with Django (or any WSGI application for that matter)?


There are two camps for distributing apps in django. It also depends on what you mean by apps.
If you mean an apps is in django terms as in 'pluggable apps' that is separated from the project, then it would be best to use setuptools to package those 'pluggable apps'. Many django 'pluggable apps' are distributed like this. For example:
django-tagging
django-registration
etc.
But if you mean an apps is a full-blown apps (the whole war file) as in Java EE terms, then you would have all off your apps inside a your project, and you would just distribute the project in any forms. Normally you would just zip it. You don't need to install it with setuptools or what so ever, as you would run your project from the project folder. Examples in this camps are:
Pinax
Satchmo
The first way is convenient if you already have django project running and you want to re-use those pluggable apps in many other projects. This is really good if you are building non-monolithic web application or an in-house application/websites or a reusable application . It's also convenient if you are managing your project and those pluggable apps by yourself. It's sort of inconvenient (to some extent) if you want to sell an apps to a customer with this kind of approach because your project and your pluggable apps lives in a different directories. Some people said that they don't have any issues with this approach.
The second way would be more convenient if you are selling your apps to a client because all of the apps is inside your project and you would only extract your project when you are at the client side. This style is more often called the monolithic style. Java EE and Ruby on Rails have a monolithic deployment style. You wouldn't need to install your 'pluggable apps' one by one (assuming you don't use any external pluggable apps in your project) when you are at the client side. But again, you would have some issues if you want to reuse those small apps inside the projects. If you don't have any plan to re-use those small apps, then this way is good enough.


setuptools is a common way to distribute any Python packages, Django apps included, and many of the more substantial Django apps (Pinax comes to mind) will either distribute through the cheeseshop or as tarballs or zips with setuptools-produced setup.py files.
Less substantial reusable apps will just distribute as compressed files, which works fine as they should be highly portable.


A django app is not much different from a python module, which you can package using python's setuptools.

Related

monolithic or microservice concept

I have a very large django project with many features that uses django as backend framework. My project lets users use both a website and a iOS app.
I am researching using a monolithic app (currently using monolithic) vs micro services, I watched this video but one part really throws me off. At 1:05, he previews his 'monolithic' app before he changes to micro services, which to me looks like a single project with a bunch of different apps.
1) Are these technically just folders and not apps? These (what i would assume he calls folders) all have a models.py and views.py and most have a admin.py.
2) What makes this a monolithic app? Is it just because he doesn't simply use django-admin startapp in the terminal to create these 'folders'?
3) Or are microservices multiple projects connected and not simply multiple apps in a single project?
My biggest confusion is with the previewed project in the video because before then I thought I had a good grasp on these concepts. I was simply looking to change to microservices, after this part in the video I'm not sure I even know what a monolithic app really is.

The main difference between a monolith and a microservice is more about how they are deployed. A monolith is one large app that must be deployed all-or-nothing. Microservices are many "apps" that work together to achieve their purpose, and each can be deployed separately. Typically monoliths are more difficult to deploy, and involve more risk since the entire system can crash if they are badly deployed. For Microservices, each only handles part of the business processing so, in theory, if one is deployed badly only part of the app goes down.

This is just a conflation of terminology.
In the context of monolithic apps vs. microservices, "application" refers to a web application, or in this case more specifically a WSGI application. A Django project is usually deployed as a WSGI application. So a monolithic app would be a deployment of a huge Django project, while microservices would be multiple smaller Django projects that are deployed separately.
"Monolithic app" may sometimes be used to refer to a Django application, i.e. a python module that is in INSTALLED_APPS. However, in that case you wouldn't be talking about microservices.

ember-cli project within Django application

Up till now I was using ember by including all required vendor files in Django static folders. With the rise of ember-cli more and more ember related files are not available in stand-alone version. They require using npm and/or ember-cli.
Ember-cli uses npm, and it creates and manages its own files, create all project files and manages loading them... so now how can I integrate than withing a Django application. Like:
I want to hook up an ember application on a given page in Django. ember-cli doesn't seems to cover such scenarios?
all vendor files (JS and other) must be served by Django / found by staticfiles finders. npm won't install to Django project staticfiles directory.
and it would be good to be able to collect files/make apps withing separate subfolders so that older apps won't break when newer app pulls newer vendor files etc.
So is that somewhat doable with ember-cli and Django? What is the best way to handle such projects?

You are going to need to set up a build and deployment process in order to deploy the assets built by Ember so that they can be served by your Django application.
I want to hook up an ember application on a given page in Django.
ember-cli doesn't seems to cover such scenarios?
You can most definitely have an Ember application live within a Django page. Set up your appplication outlet within the page served by Django.
all vendor files (JS and other) must be served by Django / found by
staticfiles finders. npm won't install to Django project staticfiles
directory.
Set up a process that copies the dependencies downloaded by npm to the static files
directory as part of your deployment.
and it would be good to be able to collect files/make apps withing
separate subfolders so that older apps won't break when newer app
pulls newer vendor files etc.
It would seem an equaly bad idea to have multiple copies of the same dependency floating around -- especially if a single user will navigate to multiple ember applications hosted on various pages of your Django app which rely on the same libraries. You will have to make a choice of whether to try to maintain the depencies for each of your Ember applications individually or to ugrade depencies across each of them at the same time. This will depend on your needs and how tightly coupled the functionality in each of your apps is.

Share NodeJS Apps like Django

I come from a Django background, where to add functionality to the site you make an app. You can share that app between other Django projects.
In the Node world I haven't really seen anything like this. However, I want to write code that is reusable and useful to the community. So I'm wondering:
Do Node programmers share apps?
How would I structure an app so that it would be easy for someone to add to their site?

Node.js developers share functional packages of code called modules through the npm registry. The modules are used the same way as the modules shown in the documentation, and are typically utilized with require(). However, do take note that Django is a web framework, and Node is a programming language. Node is to Python as something like Express would be to Django.
There isn't any specific way to structure a Node module. You just need to make sure that the package.json file is configured correctly so that the module can download any dependencies, set any binaries, and do general setup correctly.

Using 3rd party Apps in Django, some questions

I am new to Django.
I have some doubts about installing 3rd party Apps in Django.
A specific example. The "django-registration" App in https://bitbucket.org/ubernostrum/django-registration/src. Reading the instructions the doc tell us to install this app with PIP(pip install django-registration), doing this the App will be installed in Python Site-packages, right?
My question is: The App must to be installed in that way? Why not put the 'django-registration' folder in our Project as an App?
PS: This is a starter Django Question.
Best Regards,

The App must to be installed in that way?
No.
As long as python can find it (ie: it's on the PYTHONPATH) you can put it any place you like.
Why not put the 'django-registration' folder in our Project as an App?
Why not indeed? If you plan on modifying it substantially that's perhaps quite reasonable. If you aren't, then keeping it separate will keep it plain as to what is your code and what is not; and ease the updates to either.

Django and App Engine

I wanted to check the status of running Django on the Google App Engine currently and what the benefits of running django on GAE over simply using Webapp.
Django main killer feature, IMHO, is the reuseable apps and middleware. Unfortunately, most current Django apps use models or model forms (django-tags, django-reviews, django-profiles, Pinax apps).
So what are the remaining features or benefits that django has that can still run in Google App Engine (other than what's disabled: the popular django apps, session and authentication middleware, users and admin, models, etc).
Also, is there a list of the Django apps that work in App Engine as well?

app-engine-patch currently has the most of django functional, including sessions, contrib.auth, sites, and some other standard django apps. However, its main drawback (my opinion) is that it uses a zip file of a modified version of django to achieve this functionality and the current maintainers don't seem to have kept pace with current django releases. Currently it seems to be the consensus of the past and present maintainers that this approach is too cumbersome to maintain and therefore no one is currently maintaining it.
google-app-engine-django, uses a monkey patch approach of the latest django version included in the production GAE runtime, so as long as google continues to track django releases you'll be kept up to date regarding django. However, it currently has not fully ported contrib.auth, so you can only authenticate with google accounts - which can be a big drawback depending on whether you want contrib.auth User models to work as you know them on sql backends. There is also no django admin support in the helper as there is in app-engine-patch. A fork of django-app-engine-django exists which adds in some of the contrib apps, such as flatpages, sites, and sitemaps. Also note, it only works on django versions up to 1.1, until issue #3230 Django 1.2 is added to use_library, unless you upload django as a zip file.
On the horizon, the original developer of app-engine-patch has been working on the django-nonrel branch, but this may be pretty far away from being included in a django release. This django developers thread has a lot of information about these efforts.
Separately, there is a google summer of code project working on integrating some aspects of nonrel db's.

app-engine-patch gets most of those things working inside AppEngine - so you can (mostly) use straight Modelforms, use the Django users and admin, etc.
I've only used it for fairly simple projects (being quite new to django), but they claim that most Django apps will work with (at most) minor modifications on appengine. For instance, app-engine-patch uses the AppEngine Model classes rather than the Django classes; and there are some of the basic views that are too inefficient to run on Appengine.
added: google-app-engine-django is similar; but provides a BaseModel that appears identical to Django's BaseModel. My understand is that google-app-engine-django was released by Google, then forked to create app-engine-patch. The maintainers of app-engine-patch seem to have some different goals from the creators of google-app-engine-django, so you may find that one of the two suits your needs better than the other.
Google have provided some articles on running Django apps on appengine; the most recent is actually a guest post from the authors of app-engine-patch.

I've had the best success by simply picking and choosing the Django features that I need and patching them into webapp myself. In my latest project I actually just cut out the webapp stuff entirely. I still import and call several webapp utility functions, but it is mostly a hand rolled application built from the good parts of GAE and Django.

You might be interested to check out web2py, another Python framework that supposedly has less friction between GAE and a "normal" web server.

It is now quite easy to use full Django on GAE:
https://developers.google.com/appengine/articles/django-nonrel#ps

The Django version provided with App Engine has been updated to 1.2.5 with the latest SDK release (1.4.2, changelog). This version is available through the use_library() declaration, so you no longer need to mess around with monkey patching to the same extent.

The GoogleAppEngine (GAE) Python 2.7 runtime provides several third-party libraries that your application can use, in addition to the Python standard library, GAE tools, and GAE Python runtime environment. One of them is Django. The below is copied from the GAE docs page on third-party libraries:
To use Django in Python 2.7, specify the WSGI application and Django library in app.yaml:
...
handlers:
- url: /.*
script: main.app # a WSGI application in the main module's global scope
libraries:
- name: django
version: "1.2"