I actually had a go at this myself 15 years ago, with a project I called Djng: https://github.com/simonw/djng - more details on that here: https://simonwillison.net/2009/May/19/djng/
For me the two missing pieces were models and a path to migrate to a full project once it outgrew a single file, so I wrote nanodjango (https://github.com/radiac/nanodjango/, formerly django-flasky) - you can use the ORM and admin site, and I recently added a "convert" command to automatically break up a single page app into a full Django project structure.
I've been using it for a couple of years for prototyping/experimenting and putting together small apps, and with the new features this year feels like it's a really practical alternative to flask.
The human soul yearns for the simplicity of php or cgi-bin hosting, without the horrors of PHP or C
Are you planning to add some kind of API serving functionality (either by integrating something like Django Ninja or even raw Pydantic)? I think such single file frameworks are great candidates to implement microservices.
As a Django user that shares your frustrations with settings.py, I wish this had panned out.
I wasn't particularly good at sticking with open source projects like this and pushing them forwards back in 2009. I've since learned how to do that but it took me another decade to get there.
Some years back when I had to do some quick and dirty projects, I chose to go with Flask because of how dirt simple it was to start.
All the Django books and tutorials had this hidden magic abstraction feel to them after:
$ django-admin startproject <project-name> .
$ python manage.py startapp <app-name>
Django just needs to add Pydantic integration.
It's very easy to use but it's also very limited and i often find myself dropping down to RawSQL or even having SQLA connection in my Django projects.
Going with fastapi and sqlalchemy, there is no django admin and no user management out of the box.
But writing serialisers for DRF feels dated.
I cannot fathom what is the GDP impact that these folks enabled.
I tried myself about five years ago. My idea was to make a tool that could make a HTTP service from any Python file with very simple setup. With all the features of Django at the ready. Unfortunately neither Django's configuration system nor Python import methods made it reliable enough. Or I just couldn't hack it. This was the smallest I managed:
from django.urls import path
from django.http import HttpResponse
CONF = {
"INSTALLED_APPS": ["serverless"],
"ROOT_URLCONF": (path("", lambda x: HttpResponse("look ma, no server")),),
"DEBUG": True,
"SECRET_KEY": "randobrando"
}
If you're still interested in this work, I suggest checking out nanodjango, which was mentioned earlier in this thread. That project is new, but there's a plan from the outset for how people can transition from the single-file based version to a standard Django project. You might also want to check out Andrew Godwin's django-singlefile project. It's meant to support small flask-like projects, where you don't have any intention of expanding out into a standard Django project.
Both of these projects have their own code that takes what's included in the small file and tells Django how to make sense of it. That's much different than the projects that are only trying to make use of what's included in Django itself.
(I'm the author of the Django from first principles series that was submitted here, but I didn't see it on HN until this morning.)
nanodjango: https://github.com/radiac/nanodjango
django-singlefile: https://github.com/andrewgodwin/django-singlefile
In regards to nanodjango I shall take a look. Also, need to read the rest of your articles. Thank you for writing them! I’d still like to experiment with the idea of small, independent, pluggable apps. Perhaps Django can be coaxed to this now.
[0] https://www.oreilly.com/library/view/lightweight-django/9781...
- part 2: https://www.mostlypython.com/django-from-first-principles-pa...
- part 3: https://www.mostlypython.com/django-from-first-principles-pa...
also here's the repo: https://github.com/ehmatthes/django-first-principles/
This is not so useful in a real project, but good as a learning exercises to see what comprises the core of a Phoenix application.
https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
FWIW, everything starts in your project's `lib/project/application.ex` file. All the things in the `start` function dictate the "flow" of the application.