#28236 closed New feature (needsnewfeatureprocess)
Integrate dj-database-url into Django
| Reported by: | Kenneth Reitz | Owned by: | Johannes Maron |
|---|---|---|---|
| Component: | Core (Other) | Version: | 1.11 |
| Severity: | Normal | Keywords: | settings, dj-database-url, database_url |
| Cc: | jacobian@…, Tom Forbes, Johannes Maron | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
dj-database-url gives Django developers two main things:
- the ability to represent their database settings via a string (a-la sqlalchemy); very useful for environmnent variables and 12factor apps.
- it will automatically use the DATABASE_URL environment variable, if present.
I'm not sure if #2 is appropriate for Django Core (but it would be nice, as Gunicorn supports both PORT and WEB_CONCURRENCY), but I know #1 is perfect. This plan has previously been discussed (at a conference, DjangoCon EU in Zurich, long ago) and approved by JKM, before his role at Heroku, if that is helpful information.
I think this change would vastly improve the usability of Django, and would be an excellent and simple move for the project.
Many thanks for your consideration. <3
--
Kenneth Reitz
P.S. There is no "Settings" component in the issue tracker, that I can find.
Change History (12)
comment:1 by , 9 years ago
| Summary: | Integrate dj-database-url into Django Core → Integrate dj-database-url into Django |
|---|---|
| Triage Stage: | Unreviewed → Someday/Maybe |
| Type: | Uncategorized → New feature |
comment:4 by , 9 years ago
I've made an initial PR: https://github.com/django/django/pull/8562
I copied most of the 'guts' of the library and fixed up all the tests.
I don't think this is anywhere near ready to merge, but I like the idea and I thought I would take the first step and propose one way to integrate the library.
comment:5 by , 8 years ago
| Cc: | added |
|---|---|
| Has patch: | set |
I've removed the WIP from my branch as I think the implementation is ready to be discussed. I've got all tests to pass and a mechanism for configuring both the caches and the databases via URLs.
comment:6 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:7 by , 2 weeks ago
| Has patch: | unset |
|---|---|
| Owner: | removed |
| Status: | assigned → new |
| UI/UX: | unset |
comment:8 by , 2 weeks ago
| Cc: | added |
|---|
comment:9 by , 9 days ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:10 by , 8 days ago
| Resolution: | → needsnewfeatureprocess |
|---|---|
| Status: | assigned → closed |
| Triage Stage: | Someday/Maybe → Unreviewed |
Thanks for the bump. Reading the linked forum thread, the last post says "shall we wontfix this?" and repoints to a forum discussion about a settings refactor. There's also a more recent forum thread on the sketch of a settings refactor.
I think the new features process is the next place to go to consolidate ideas and gather implementers.
comment:11 by , 8 days ago
@Jacob, great, I opened a new-feature ticket and then closed it after realizing there was an accepted ticket. And now I put a day of work into it. A little frustrating, to be honest.
The second link you shared isn't public.
The first one mentions an important scope limitation, which I agree with. The DEP request was mainly regarding loading environment variables.
Are we still testing the new-feature process, or is it the official default now? Should any accepted feature ticket be closed then?
comment:12 by , 8 days ago
I reopened it, while I still find the back and forth very frustrating, considering the decade of history on this ticket.
It's better to propose something like this on the DevelopersMailingList where it'll receive more feedback.