We Keep Coding

Referencing multiple Django projects from a single monorepo

I want to be able to write shared functions that can be accessed in one-off batch scripts and also by the running Django service (to use the ORM)
Currently, I have this in the _init__.py under the my_proj module.
if 'DJANGO_SETTINGS_MODULE' not in os.environ:
os.environ['DJANGO_SETTINGS_MODULE'] = 'my_proj.blah.blah.settings'
import django
django.setup()
This works fine for one django project. However, now I want to do reference the ORM functions from another django project, "other_proj" in the same repo from an independent script that lives outside both django projects.
Is there a way to "django.setup()" multiple projects at once?
Or, at least, a way to easily toggle the setup between the two projects?
Or is there a better way altogether? (I realize I could create a client library to hit the services while they are running, but would prefer to remove that overhead)

If you want a Django project to access functionality that resides in a different Django project, a client library is an option (as you noted). You could also consider packaging those sets of functionality as re-usable Django apps that you import into each project, or you could abstract them further into re-usable Python modules which get imported into each project. If you're hoping to use the Django ORM from one Project to access data from a different project, then you might be looking for this SO question: How to make two django projects share the same database
I think with more specifics in your question (such as, for example, function X in Project A you wish you could call from Project B) we might be able to be more specific with guidance.

I'm not sure I quite understand the case you're trying to implement here; two things that sound maybe-sort-of like what you're asking for are:
1) Running Django projects under uWSGI in Emperor mode allows you to serve multiple Django projects from one server simultaneously.
2) Django can be configured to run the same project under multiple domains simultaneously using the Sites framework.
I agree, though, that more detail about what you have and what you're trying to accomplish with it is probably necessary to give a satisfying answer.

how to handle common code in a django project which is used by multiple apps

diving deeper into django I came across the challenge to handle code which is not specific to 1 app but is shared/used by multiple apps.
I would not(!) like to store it as part of an app (to avoid app dependencies) but to have it in a specific place.
currently my best practice is to create a django app "shared" in which I place this code/functionality
so my project structure looks similar to this:
mysite/
manage.py
mysite/
...
shared
...
app1
...
app2
...
app3
...
...
is there a "django best parctice" or a more practical way how to handle this?

I usually do exact same thing what you are doing. Not sure if that is best practice however I've seen other people using the same approach. I like it because:
when the shared/core/etc app becomes useful in other projects, you can package it as reusable app which can be installed via pip in other projects
it does not interfere with existing apps in the project
The only note about packaging it as a reusable lib is that I would recommend to rename it to something other then shared. The reasons is that when you package it in PyPI lets say as my_django_utils, then you will have to change all your imports in all the projects. If you come up with a generic name now, then you can easily package it in the future without needing to change all your imports...

My answer is inspired by the documentation found in the edx-platform github repository: inter-app-apis
Creating a shared app seems like a good idea. However, its hard to decide whether something really needs to be in a shared app in the early days of development of a project.
If you are sharing only a small set of functionality, rather than trying to completely pull the shared code into a separate app, what if you could make it easy to manage the dependency? One problem with creating any sort of dependency is that they have a way of going out of control and very soon you wont know what parts of an app does your caller depend on.
To address this, you could define a separate python module that acts as a proxy between the app that provides the shared code and the app that calls into the shared code. So if you want your app2 to use some function foo in app1, you don't directly call that function, but you write a wrapper function foo_api in a separate module (called api.py) within app1 which calls the function for you. All functions from app1 that is called by other apps would have to go through this single api layer.
By doing this, you are not eliminating the apps depending on each other, you are making it easier to find the dependencies of an app. And if you later find that there are many callers for a function, then you could think of extracting these into a separate reusable lib.

What is the best way to configure a django project

I am about to set up a project, and am wondering what the best way to do it is.
I notice some open source files have an "apps" directory, which stores all third-party apps, etc.
I was looking at the following two projects
https://github.com/josephmisiti/NewsBlur
https://github.com/dkukral/everyblock
My project will consist of code that will run multiple different (and connected) web applications.
I also found this:
https://github.com/lincolnloop/django-startproject/tree/master/django_startproject/project_template/myproject/
Thanks,

This question has been covered several times. See:
Django tips: laying out an application
Web Application (Django) typical project folder structure
Best practice folder hierarchy of a Django Web App

I don't think there is an exact 'best way' which is suitable for every project. But there are some general rules that may help you setup your project. I won't send any link about this but there are several documents and webpages, so keep Googling. It's the best way to learn some extra tricks while digging pages for a purpose.
Also, try to understand projects that is similar to the one you want to develop. You say you've been already doing it, I think it is going to be the most helpful thing you do for your project.

How to structure standard Python project (modules, libraries) for future use in Google App Engine?

I'm currently developing a Python project which is growing and I may implement it as a webapp in GAE in the future.
As the project is growing I'm pruning potentially reusable code into separate packages & modules, which at present are on my PYTHONPATH.
Do you have any advice on how to structure my project, and reusable packages so that it will fit nicely into a GAE project in the future?
Looking at recommendations on GAE project structure in other posts (such as this and this and this) seem fairly flat - is that the best way to go?
What about 3rd party packages/modules? Is it best to bite the bullet and use VirtualEnv from the beginning?
Thanks very much.
Prembo.

Just put your various libraries in packages off the root directory of your app. The root directory is automatically added to your app's sys.path.
If you wish you can put them in a lib directory off the root, you can do so, but you'll have to write a module that adds that directory to the end of sys.path, and import it before you import anything from lib.
Using virtualenv is an option, but I personally don't think it gains you much, since you can't run a virtualenv in production, and the dev_appserver emulates the production environment.

I can't tell you about GAE in particular, but I can tell you that biting the bullet has nothing to do with it - using VirtualEnv (and virtualenvwrapper) will make your Python development smoother, simpler, and easier all around.
The over head is low, the benefits are many.
Switch. Now.

My master thesis as a student was implemented in App Engine. The project is open source and you can use it however you like, I hope you will get the idea and you might adapt it to your needs.

The GAE Python SDK creates its own Virtual Environment when running on your local environment, so virtualenv won't help you much. There are frameworks like web2py and django-nonrel that works well with GAE, if you're up to porting your code, or at least take inspiration on their folder structure.

What's your folder layout for a Flask app divided in modules?

I am experimenting with Flask coming from Django and I really like it. There is just one problem that I ran into. I read the flask docs and the part about big applications or something like that and it explains a way to divide your project in packages, each one with its own static and templates folder as well as its own views module. the thing is that I cannot find a way that works to put the models in there using SQLAlchemy with the Flask extension. It works from the interactive prompt to create the tables, but when i use it inside the code it breaks. So I wanted to know how more experienced Flask developers solved this.

While I'm not ready to announce because I'm still actively working on refining the samples, you would probably benefit from the flask-skeleton project that I'm developing. I got tired of reinventing the wheel with regards to bootstrapping Flask websites so I started to a complete sample project that uses my best practices. I haven't added any unit tests yet, but this should be good enough for you to start with. Please send me feedback or suggestions if you come across any.
https://github.com/sean-/flask-skeleton/

Actually I found out what I was looking for. Instead of importing flaskext.sqlalchemy on the main __init__ you import it in the model. After that you import the model in the main __init__ and with db.init_app() start it and pass the app configurations. It is not as flexible as the skeleton shown in #Sean post, but it was what I wanted to know. If i weren't toying around probably the skeleton would be the one I'd use.