We Keep Coding

Is a django project only meant to be for a single website or can the different apps be different sites. What is perferable and advisable?

I have been using django for a while, but there is something im not quite clear on.
How big should a django app be. If for example a django app should only be user authentication or if it should be an entire website in one app.
If I have a project with several apps and each app is a whole website with a lot of code, is that the way it suppose to be or should all apps related to a single site within a project ?
Im thinking of creating one django project for each site, but im now wondering if I should be creating one project where each app is one site. Can anyone please comment on this, what it the preferred way to do it ?
In the django documentation one app is only used for a poll, so it seems to be that, according to the documentation, that each app should be some part of functionality on the site.

An app is a submodule of a project which contains functionality (views, models, urls etc) for a specific part of the larger site and is as decoupled from the other apps as possible. The project as a whole is the website and your apps make up the separate parts of functionality for your site.
If your sites are going to basically contain the same functionality, it might be worth looking into the Sites framework which django provides.
So taking the polls example further.
Lets say the website is a survey site. There would be the polls app, which would contain the relevant models and views for creating and recording poll results. Then you might need to view the data, so you could create an analysis app, which would store the views for displaying dashboards and contain functions for data processing. Then we could take things a bit further, and have users be able to log in and see their own results (and give us the chance to link users to poll results), so you would make an accounts app, which would hold views for logging in/out, maybe a profile page etc.
So each of these different parts of functionality would be separated out into distinct apps, which would make up the project (site) as a whole.
If the apps have been decoupled properly, you could reuse the different apps in other projects (e.g. the accounts app could be dropped into a new project do provide logging in/out functionality)

In my experience so far, an app should be a reusable entity. There many guiding principles for choosing what to go and what not in an app. Separating authentication is one example. A projcet is one big collection of may apps and a reusable app can be in many projects.
Nowadays, there is a trend to move to micro service architecture, which is next level of separation of functionality with each service doing best one thing.
Each project is a unit in itself, not an individual app. So you host the project, not the app. I recommend using different project for each site and using micro-service architecture. A lot depends on your existing codebase too.

Can I Run Multiple Django Projects on One Website?

i'm a bit of a newcomer to Django/Python but trying to figure something out--hope you can help.
I'm trying to create a personal website with a page dedicated to some of the Python and Django projects that I've completed through several different online courses.
I'm just having a tough time figuring out the best way to link through and assemble the project directories on my server.
My first project is just the files for my blog itself. I've created a new directory in the same home root as the blog project housing another of my django projects. Just looking for a bit of assistance on how i link out to the second project from my blog.
I thought i could use the urls.py file for my blog to redirect link to the second project (ie projects/project2) utilizing a views definition from the views.py file for one of the apps in the blog. But then--i'm getting tripped up on how to render that link to the second project.
Any forward guidance is greatly appreciated.

In general, anything that makes sense to be served under different domain (not necessarily subdomain) would better be a separate project for sure. Exceptional case would be a project with almost same functionality but different branding within same organization. In such case, Django's built-in sites framework can be considered.
For different projects, you need different project roots along with different wsgi/port bindings and processes. They can still be listed within a single nginx configuration as a deployment example. Another popular way is using Docker but deployment methods vary.
For different apps in a single project, there is only one binding and one root already. Create apps and list them in your settings.py and urls.py. If you need subdomains with single deployment, tkaemming/django-subdomains might be helpful.
For different policies (rarely) in a single app under different domains, learn about sites framework. You need to hand code the difference in views.
and so on...

django oscar and djangocms

I am interested in combining django-cms for content management and django oscar for e-commerce.
Can someone give me some direction, preferably someone that has already successfully combined the two:
[A] Should the structure be a base oscar site, with the oscar templates modified to insert the necessary placeholders to permit cms etc...,
OR
[B] Should the structure be a base django-cms site, with oscar being handled by plugins etc...
My gut feeling is that it should be [A], but please correct me if I am wrong.
Any other suggestions would be appreciated, as there is little online, and I have written to the author of oscar with no response. I am aware of THIS link, which doesn't address implementation, only comparing compatibilities.

This combination is something that I've been looking at for a while and actually had a working prototype. Without knowing your full use case it's difficult to advise properly.
What I required sounds very similar to you, a site that can have CMS editable pages on the same sub domain (e.g. www.myshop.uk/shop www.myshop.uk/cms-pages) as the oscar provided pages. I wanted to have the initial homepage driven by the CMS and a separate area of the site for the E-commerce pages.
If your requirements are the same as mine, the best way to achieve the integration is via an app hook in Django CMS, this would mean that the CMS is the controlling package: http://docs.django-cms.org/en/release-3.3.x/how_to/apphooks.html
I used the following documentation, the code didn't work on more recent versions of Oscar and CMS but was a good guide of what should be possible and a push in the right direction: https://pypi.python.org/pypi/djangocms-oscar/0.1
I will be attempting this again very soon as I have a new site where the CMS and E-commerce site are separate and need merging under the same sub domain.
Is this still an issue for you?
I am considering either contacting the author about updating the previous project "djangocms-oscar" or creating a new one with supporting docs for others.

I have worked on the very similar configuration you have asked here. A pure blend of django-cms with django-oscar.
Here's what I did and it works perfectly fine.
First setup a new project with cookiecutter-django-cms
Then install django-oscar inside it.
Setup your shop.
As long as I know, it works fine.

Pre-configured Python web framework with Authentication, Profiles, etc

I want port some my Python scripts into web apps so that others can use it and I'll use some sort of web framework. I've been playing around with Django lately but it doesn't have the basic user registration, email verification stuff built in and one would probably end up using django-registration.
Almost all web applications require you to create an account, verify your account by clicking that verification link in your account and so on. One would save a lot of time if he could just skip past the part of setting up authentication, verification, the usual log-in and log-out pages and get to part of doing the "core" part.
Has anyone come across a pre-configured Python web-framework (Django would be nice) that does the all usual basic stuff? Django has that contrib.auth bit you can add django-registration
(I hope this question sounds reasonable.)
Thanks.

Take a look at Pinax ( http://pinaxproject.com/ ), which consists of a set of Django apps that take care of some of the most common tasks. Including the user registration one you outlined.
However, this is actually not very difficult to build. You are right, most sides need it, but implementing it even from scratch is pretty easy.

web2py take a look at Access Control Chapter in http://web2py.com/book

Django: Admin with multiple sites & languages

I'm supposed to build some Django apps, that allow you to administer multiple sites through one backend. The contrib.sites framework is quite perfect for my purposes. I can run multiple instances of manage.py with different settings for each site; but how should django's admin deal with different settings for different sites, eg. if they have different sets of languages, a different (default) language? So there are some problem s to face if you have to work on objects coming from different sites in one admin...
I think settings.ADMIN_FOR is supposed to be quite helpful for cases like this, but theres hardly any documentation about it and I think it's not really used in the actual Django version (?).
So any ideas/solutions are welcome and much appreciated!
Thanks a lot...

There is an old blog post by James Bennet which might be helpful:
Create a new Site object in your admin for each domain, and put the id of that Site into its settings file as SITE_ID so Django knows which site in the database corresponds to this settings file.
In the settings file for your original site (the one with id 1), add the other sites’ settings files to the ADMIN_FOR setting, to let Django know that this one instance of the admin application will handle all of the sites.
As documented ADMIN_FOR (for which i can not post link) should be a tuple of settings modules much like INSTALED_APPS is a tuple of django app modules.
Note that blog post is from 2006 so it uses a bit outdated API.