Extract Django ORM into a Standalone Package

[nndnha]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

I propose extracting Django's ORM and its migrations framework into a standalone Python package, similar to SQLAlchemy, to make it reusable outside the full Django framework.

Problem

This would allow developers to leverage Django's powerful ORM and migration tools in non-Django projects, fostering broader adoption and community contributions.

Request or proposal

request

Additional Details

No response

Implementation Suggestions

No response

[github-actions]

Thank you nndnha for sharing your idea! We have a lot of them so please be patient. You can see the current queue here. If you'd like to learn about other ways to get this idea more attention, please see this page.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[nanuxbe]

Given this is a request and not a proposal and the general enthusiasm, would this happen to be a good candidate to flag as "sponsorable" feature?

[carltongibson]

There's a long standing desire to make the ORM easier to use outside of a regular Django project. (Script usage for example.)

(I can't find a ticket for it right now 📱)

This is already do-able but you need to do things like configure the settings and such, which isn't always obvious. And it's not clearly documented.

Actually extracting the ORM looks like a very big lift. Maybe it's possible but the most likely outcome is a bit of preliminary investigation and then nothing. (Happy to be proven wrong.)

I'd suggest waypoints around the easing of allowing folks to use the ORM in scripts (non-web contexts) wouldn't be wasted effort. They'd be necessary anyway. Would be independently valuable. And may capture 90% of what's really wanted here anyway.

(I suspect there are few cases where it really matters that you get the bits of Django you're not using downloaded when you install Django for the bits you are using.)

[nanuxbe]

@carltongibson do you think this (correct settings and other configuration to only use the ORM) could be achievable with the proposed new command as one of the proposed templates?

[carltongibson]

@nanuxbe That's a good question. Maybe, yes.

I asked for a bit of input on patterns here:

https://fosstodon.org/@carlton/114437459643045544

(At the least we could document this up! 🫠)

[collinanderson]

Just curious: does it actually need to be a separate package, or is the main issue the ability to use the ORM without calling settings.configure() / django.setup() first? (or what advantage does a separate package give besides that?)

[VaZark]

If I may chime in with my two cents, I would say portability is the biggest factor.

As someone who works primarily with Django, sometimes I need to write scripts or build/manage an existing Flask app that requires DB access. Being able to reuse Django's expressive ORM would make life simpler, as we would not need to relearn new semantics for the same operations (like SQLAlchemy)

It would also make it possible to deploy a leaner Django if we could choose not to have the ORM or form as part of the project (I have quite a few views, whose only purpose is to collect and forward data, which uses Flask)

The better perspective might be to view this as a request as a means to expanding the use cases for the Django the project and not necessarily _Django the framework

That said, it's up to the core team to evaluate if this is worth all the effort this would require.