Pre-proposal: adopt dj-database-url as a DEP 7 official project

[Jacob Kaplan-Moss]

Hi folks -

I’d like to gauge interest in adopting dj-database-url
(http://github.com/jacobian/dj-database-url) as an official project
(https://github.com/django/deps/blob/master/final/0007-official-projects.rst).
This is my pre-proposal. I think dj-database-url is very widely-used, and
scratches a specific but annoying itch. Maintenance burden is minimal, but
important.

What do other folks think? DEP 7 asks us to

> solicit feedback from the community and work out if there is rough agreement
> that the project is a good thing for Django to adopt, particularly focusing on
> any alternative approaches to the same problem and the relative merits of them,
> including code design, scalability, alignment with existing Django design and
> philosophy, and having an available development and maintenance team.

So - thoughts?

I'm volunteering to be the shepherd, but do intend to form a larger team.

I've also opened https://github.com/jacobian/dj-database-url/issues/120
as another place for this discussion. Please feel free to comment either
place.

[Backstory, and why this is living on my github right now. @kennethreitz was
looking for a new maintainer, and reached out to me to see if Django might be
interested. I thought perhaps so, and offered to take over maintainership in the
meantime while we work through the DEP 7 process. If it turns out that an
Official Project is the wrong home for this, I'll either maintain it long-term
or transfer it again.]

Jacob

[Tobias McNulty]

I think it's a great idea.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c4044098-d97f-44be-8859-b05cb594a7be%40Spark.
For more options, visit https://groups.google.com/d/optout.

[Adam Johnson]

+1 from me too.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRakWoQYehp_ccnhTvbQWY3a2CN2k_iob2fsL7bwv%2BRcQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Jani Tiainen]

I'm definitely +1 too.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3jWBjZVyFw-KmLRvuYaFO3p6KmYnF%3DoQNjTPR2NN%3D8Bg%40mail.gmail.com.

[Kevin Grinberg]

I've more commonly found myself using https://pypi.org/project/dsnparse/ more often than dj-database-url, due to support for DSNs in setting CACHES (with Heroku Redis for example, you get a REDIS_URL exposed the same way).

I don't think the maintainer is offering to do take dsnparse under DEP 7, so "blessed dj-database-url" may be better than the status quo, but I worry if blessing a partial solution is liable to send some folks down a less-than-ideal path (I'm imagining a new user finding dj-database-url as then "official" solution, and then getting stuck trying to wrestle with it to do "almost the same thing" with configuring CACHES).

That's not to say that dj-database-url couldn't grow into a more generic DSN parser, and maybe that's the plan - in which case, enthuastically +1! But AFAICT the diffs are not altogether trivial, and I'm not presently able to volunteer to do it, so I'm working on the assumption that dj-database-url retains more or less its present scope.

Kevin

[Mariusz Felisiak]

See a ticket [1] and previous discussion [2] for reference.

[1] - https://code.djangoproject.com/ticket/28236

[2] - https://groups.google.com/forum/#!topic/django-developers/G0TtlhH2RUE/discussion

[Raffaele Salmaso]

Hi
I'm working[¹] on https://github.com/django/django/pull/10786 which is an "evolution" of dj-database-url which handle more settings types (by default even the email settings, but it is possible to handle any other type).
I'll happy to finish it.

[¹] well, in my really little free time

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c4044098-d97f-44be-8859-b05cb594a7be%40Spark.
For more options, visit https://groups.google.com/d/optout.

--

| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

[Jani Tiainen]

Apparently there has been few attempts to integrate dj-database-url or some other url parser.

But what happened to them since so far none of them were completed?

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABgH4JvLhqgd7VPPAdaCoJ3VidZ-JaPZVbU2gMiK3_Rycxnekw%40mail.gmail.com.

[Raffaele Salmaso]

On Thu, Jul 18, 2019 at 9:49 PM Jani Tiainen <red...@gmail.com> wrote:

But what happened to them since so far none of them were completed?

For my case: life :D

Anyway, I'll be happy to finish it.

[Jacob Kaplan-Moss]

Puling together a few things:

On Jul 18, 2019, 3:13 PM -0400, Kevin Grinberg <ke...@activefrequency.com>, wrote:
> I've more commonly found myself using pypi.org/project/dsnparse/ more often

> than dj-database-url, due to support for DSNs in setting CACHES (with Heroku Redis
> for example, you get a REDIS_URL exposed the same way).

On Jul 18, 2019, 3:32 PM -0400, Raffaele Salmaso <raff...@salmaso.org>, wrote:
> I'm working on https://github.com/django/django/pull/10786 which is an
> "evolution" of dj-database-url which handle more settings types (by default
> even the email settings, but it is possible to handle any other type).
> I'll happy to finish it.

On Jul 18, 2019, 3:49 PM -0400, Jani Tiainen <red...@gmail.com>, wrote:
> Apparently there has been few attempts to integrate dj-database-url or
> some other url parser.

> But what happened to them since so far none of them were completed?

I suspect this is a "good enough is good enough" situation. Something like what
Raffaele is talking about, or dsnparse, or whatever would probably be ideal. And
for something to be merged into core, I think it'd need to be a more full
solution than just dj-database-url.

But, because dj-database-url is Good Enough, it's pretty popular, and that sucks
away some of the impetus to work on something better.

That said: were 10786 (or similar) to be merged into core, I'd think the best
thing to do wth dj-database-url would be to put it into maintenance mode, and
just fix serious issues until all of the supported version of Django have the
new thing.

I think that's somewhat unrelated to whether it becomes an official project --
just as easy to deprecate django/dj-database-url as it is to deprecate
jacobian/dj-database-url. But happy to make that an explicit caveat for
official-dom: if something better lands in core, I'd look to deprecate
and migrate.

Jacob

[Aymeric Augustin]

Hello,

In the short term, I'm in favor of moving dj-database-url to the Django organization.

I have only one concern. dj-database-url supports a few third-party database backends: https://github.com/jacobian/dj-database-url/blob/004150c17e1519be408f87e0a2d16a8633cad89f/dj_database_url.py#L34-L45 I wouldn't want this to be interpreted as an official recommendation about which backend is best for MSSQL. This isn't enough to make dj-database-url unsuitable as an official project but it's worth keeping in mind. Perhaps "mssql" should be deprecated in favor of "mssql-X", "mssql-Y" and "mssql-Z" to put every alternative on an equal footing?

In the long term, I agree that dj-database-url could be deprecated if Django gets equivalent functionality built-in. This will require a bit of creativity to avoid hardcoding mappings for third-party database backends. Probably users of third-party backends will have to add a line to register a URL scheme with a third-party backend.

Best regards,

-- 

Aymeric.