I’m just in the process of doing a little refactoring. Part of this has been renaming the project directory to “config” and moving a couple of “fake” apps in there. These are apps that only really exist to provide a little extra functionality across the project (eg. couple of extra abstract models etc.).
There are a couple of management commands that are project level as well really. Previously these have been in an “app” called “initialise”, but that app contains nothing else of value. I figured I’d move them into the project folder and remove an unnecessary app.
No joy of course, as Django looks in the app folders when searching for a management command, so it doesn’t find these commands at all.
Personally, I can see the value in allowing management commands to be defined at the project level, as well as within individual apps. I don’t see any previous discussion or issue related to this, and maybe there’s a good reason not to do it that I’m not thinking of?
Curious as to what other - more experienced - folks think.
First, as a general note, while it can be done, I always recommend that you never rename or delete an application if there are any models associated with it that have been added to your database.
(See this other thread for more details: Official CLI's command to rename an app)
Now, beyond that, our pattern is that we have a “project app” that serves as the project-specific location for entities that don’t belong to any more specific app. That includes management commands. (Side note: I’ve got at least four Django projects in production that never render web pages. They only exist to run management commands, and those management commands exist in that project-app directory.)
I, too, usually have a project-level app that services these kinds of things - often called core or common or similar. I find that easier than trying to hack in some different kind of project-level support.
This is refactoring of something that has not gone live yet, so the renaming isn’t a big deal in this instance 
It’s not a big deal, and I get that I can add another app that does this kind of stuff, it’s just that pretty much all of the other “config” stuff could be neatly refactored under the project, meaning I end up with the project folder plus another app that share project level stuff between them. Just seemed unnecessary, and was wondering if there was a reason the project folder was not checked by Django for management commands?
The only reason is that Django has only one abstraction for containing “stuff” - apps. It doesn’t have a concept of your “project” beyond where the settings file is.
I too typically have a “core” app. In fact much of the time these days I tend to stick with only “core” and never split things out.
1 Like
Fair enough, though other “config” stuff does work under the project dir, simply by virtue of it being a module (one example: adding a TimestampedModel class to be used across all apps).
Since we’ll be building probably 5 or 6 Django services, with multiple apps in each one to migrate our monolith to, I’ve been trying to come up with a decent template to reuse across services, just for consistency’s sake. Given the feedback, I’ll tweak the current approach a little
Thanks for the input, everybody!