3 ms·

If you do this a lot you should look into ‘startapp —-template’ which lets you bake in boilerplate like this. https://docs.djangoproject.com/en/4.0/ref/django-

If you do this a lot you should look into ‘startapp —-template’ which lets you bake in boilerplate like this. https://docs.djangoproject.com/en/4.0/ref/django-admin/#cmdoption-startapp-template https://docs.djangoproject.com/en/4.0/ref/django-admin/#cmdo... One minor point on app names. They are really hard/annoying to change once you have production data, because your DB tables will always be appname_modelname, and renaming tables is a real PITA. You can set the model to point to a nonstandard table, but then your project has a confusing non-Djangonic wart that will annoy you forever more. For this reason I think ‘core’ is a safer option, unless you are certain what your app should be named. Naming after one domain model is likely to be too specific. (I strongly recommend against multiple apps until you have functionality you need to commonize between projects, as refactoring models between apps is a nightmare if you get the boundaries wrong.)

chomp 4y ago
> For this reason I think ‘core’ is a safer option, unless you are certain what your app should be named. Yep, this is what I do. It’s rare that I make anything that can be shared cross-app (most Django apps I make are super simple CRUD-types), so every one of my Django apps has a ‘core’. I also recommend this approach.
saila 4y ago
Regarding apps, I was just thinking you could create a directory structure like this, essentially eschewing the whole concept of Django "apps": <project> src/ <package>/ models/ __init__.py # Import all model classes (necessary for Django to find them) some_model.py # Define SomeModel class views/ __init__.py some_view.py # Views for SomeModel settings.py # Add "<package>" to INSTALLED_APPS urls.py You still need to register the top level package as an app for Django to find things, but then you don't have to deal with Django's concept of apps beyond that. All your tables will be named <package>_<model> by default, which seems nice. If it turns out later you need resusable "apps" for some reason, you could always add an apps/ subpackage for them. I haven't tried this in a real project, so I don't know if there are any downsides, but it seems like a decent approach.
- theptip 4y ago
  Yeah I've played around with this approach in the past while prototyping service boilerplates, I think it's viable. I never got it polished enough to publish as a startproject --template and ultimately went with Flask for microservices, so I didn't finish the prototype. I found this article useful while I was experimenting: https://simpleisbetterthancomplex.com/article/2017/08/07/a-minimal-django-application.html https://simpleisbetterthancomplex.com/article/2017/08/07/a-m... There are a few different places where little things break and then you need to use an obscure settings.py variable to fix them, which makes me a little nervous since it will cause a little cognitive friction for Django-fluent developers joining your project. But I do think it's worth experimenting with.

chomp 4y ago

> For this reason I think ‘core’ is a safer option, unless you are certain what your app should be named. Yep, this is what I do. It’s rare that I make anything that can be shared cross-app (most Django apps I make are super simple CRUD-types), so every one of my Django apps has a ‘core’. I also recommend this approach.

saila 4y ago

Regarding apps, I was just thinking you could create a directory structure like this, essentially eschewing the whole concept of Django "apps": <project> src/ <package>/ models/ __init__.py # Import all model classes (necessary for Django to find them) some_model.py # Define SomeModel class views/ __init__.py some_view.py # Views for SomeModel settings.py # Add "<package>" to INSTALLED_APPS urls.py You still need to register the top level package as an app for Django to find things, but then you don't have to deal with Django's concept of apps beyond that. All your tables will be named <package>_<model> by default, which seems nice. If it turns out later you need resusable "apps" for some reason, you could always add an apps/ subpackage for them. I haven't tried this in a real project, so I don't know if there are any downsides, but it seems like a decent approach.

theptip 4y ago
Yeah I've played around with this approach in the past while prototyping service boilerplates, I think it's viable. I never got it polished enough to publish as a startproject --template and ultimately went with Flask for microservices, so I didn't finish the prototype. I found this article useful while I was experimenting: https://simpleisbetterthancomplex.com/article/2017/08/07/a-minimal-django-application.html https://simpleisbetterthancomplex.com/article/2017/08/07/a-m... There are a few different places where little things break and then you need to use an obscure settings.py variable to fix them, which makes me a little nervous since it will cause a little cognitive friction for Django-fluent developers joining your project. But I do think it's worth experimenting with.