Re: ticket 5929

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Thank you Barhamou for raising the question here and starting the
discussion.

I agree with Adrian that this feels like a pretty niche use case.
Depending on the needs, other possible implementations might include:

4. A form field mapping to multiple model fields
5. A custom queryset/manager that takes "shorthand filter queries" and
expands them to multiple model fields

As for the example in #5929  ticket
description, that is probably best solved with #2 on Adrian's list, for
example the django-netfields
 project
for Postgres.

On Mon, Jan 9, 2023 at 9:59 AM Barhamou Hama  wrote:

> Hence the interest of my question, if in 15 years it has not been solved,
> there must be a reason.
>
> Le lundi 9 janvier 2023 à 12:57:31 UTC+1, ator...@redhat.com a écrit :
>
>> I feel like this is a very niche use case and probably doesn't warrant
>> implementing field-to-column one-to-many relationships in Django, I don't
>> see why this specific case can't be implemented as:
>>
>> 1. A model that implements the data type
>> 2. A custom field + custom datatype on the database backend
>> 3. ArrayField [1] if using postgres
>>
>> [1]
>> https://docs.djangoproject.com/en/4.1/ref/contrib/postgres/fields/#arrayfield
>> On Monday, January 9, 2023 at 12:16:56 AM UTC+1 cur...@tinbrain.net
>> wrote:
>>
>>> On Sun, 8 Jan 2023, at 23:29, Barhamou Hama wrote:
>>>
>>> Hi all, I came across this ticket here
>>>  opened 15 years ago that
>>> doesn't seem to have been resolved. I decided to work on it. But in 15
>>> years a lot can happen. Is it still relevant? Has there been any progress
>>> on this issue?
>>>
>>>
>>>
>>> IIRC there's no current support for this, the closest being
>>> GenericForeignKeys, which still require their sub-fields defined separately.
>>>
>>> There has been posts about supporting joint using multi-field keys (
>>> https://devblog.kogan.com/blog/custom-relationships-in-django) however,
>>> that's a rather specific case.
>>>
>>> I think it would be a good thing for progress on this issue to happen.
>>>
>>> You might also want to check the ticket history for any work on
>>> multi-value keys.
>>>
>>> --
>>> Curtis
>>>
>>>
>>> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9e4ee8c9-aa22-4ac1-bd70-1c87427ca955n%40googlegroups.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKRDeF-VqnYg%2BHmTYo-pT1QyG61dUKKqm3Ai_jSKnb984g%40mail.gmail.com.

Re: #21978 include production-ready web server

['Tobias McNulty' via Django developers (Contributions to Django itself)]

At Florian's suggestion in another thread, I propose that we move further 
discussion of the settings refactor to the forum:  
https://forum.djangoproject.com/t/settings-refactor/17352

On Wednesday, November 2, 2022 at 2:58:29 PM UTC-4 f.apo...@gmail.com wrote:

> The speckenv example highlights the problems when using `literal_eval`: 
> A=[] will parse as list but A=[a] will parse as string again (if I read the 
> code correctly). This ambiguity makes it really hard to explain. When using 
> `literal_eval` one imo has to be consistent and don't fall back to a str 
> and require strings to be written as A='[]' (with quotes). Then again this 
> is rather ugly and hard to get right/explain if you try to pass that in via 
> a shell ala `A='[]' django-admin runserver` and now A is a list again :/
>
> Cheers,
> Florian
>
> On Wednesday, November 2, 2022 at 8:20:00 AM UTC+1 m...@feinheit.ch wrote:
>
>> On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner  
>> wrote:
>>
>>> Right, that would work. I am wondering though if we want to go all in on 
>>> a typed config object like that or in a first step only have a simple API 
>>> like `config.get('DEBUG', cast=bool)`.
>>>
>>>
>> I found a neat trick in a 12factor library somewhere (I don't remember 
>> where unfortunately) of using ast.literal_eval for config variables:
>> https://docs.python.org/3/library/ast.html#ast.literal_eval
>>
>> https://github.com/matthiask/speckenv/blob/94722bcc95b94a9e6b1a1aada2bd977c43bfb767/speckenv.py#L63
>>
>> This may be too cute or magical for Django. It certainly works well and 
>> avoids having to be overspecific with types. I find it boring to tell the 
>> config loader that True is a bool and "hello" is a string. That being said 
>> I don't really have a strong preference here apart from having a strong 
>> dislike for the "several settings files" pattern. It's much more obvious to 
>> me if e.g. `MIDDLEWARE` is configured in a single location and not modified 
>> in other files. 
>>
>> Thanks,
>> Matthias
>>
>>
>>
>>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c783c4b-13ec-4e23-9fe1-101b92e4c49bn%40googlegroups.com.

Re: Integrate dj-database-url into Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

I started a forum thread on the settings refactor here:
https://forum.djangoproject.com/t/settings-refactor/17352

Regarding the original topic of this thread (
https://code.djangoproject.com/ticket/28236), are we ready to close this as
wontfix? I'm okay not proceeding with it (dj-database-url, django-environ,
etc. are more than fine as stop-gaps), but it would be nice to preclude
further effort/work on this issue if we're never going to move forward with
it. While I realize it was never Accepted, that nuance may be lost on new
visitors given the prior work history on the issue...

Cheers,
Tobias

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKSHu9mx366iMkrnZseCtTaPXSbvV3dbNTLosL0B2m-L4Q%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

['Tobias McNulty' via Django developers (Contributions to Django itself)]

As someone who only just joined the forum -- I'm +1:

   - The forum has seen great adoption from what I can tell (nearly half
   the number of posts as django-developers during the same time period, not
   bad given the mailing list's head start in subscribers).
   - It seems beneficial to house future conversations in a single place,
   e.g., so members don't need to subscribe to both the mailing list and forum
   to get the full picture of current active development, set up two different
   sets of mail filters to tag things appropriately, etc...

Would the plan be to switch django-users as well? I think similar arguments
could be made for consolidating those...

(On the other hand, I see little value in switching django-announce and
django-updates, but I'm not necessarily opposed to it either, especially if
there's a way to import the subscribers to those lists...)

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson 
wrote:

> Hey Roger,
>
> Indeed it does. You can set up Email Mode (that may not be the actual
> name) and it’ll work just like a mailing list.
>
> You can also subscribe to just a particular category, so the Internals one
> would map to the discussion on this list.
>
>
>
> On Monday, 28 November 2022, Roger Gammans 
> wrote:
>
>> Hi
>>
>> I can't speak for others, but I personally STRONGLY value the fact that
>> this discussion happens in my inbox, not on yet another website.
>>
>> But perhaps the forum still supports this reading mode?
>>
>> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>>
>> Hi all.
>>
>> Given the issues with Tom's access to the mailing list here, and the fact
>> that the Forum has been active for a few years now, and is a great success,
>> I'd like to revisit whether we can move on-mass (all few of us :) over
>> there?
>>
>> We'd enjoy the benefits of a much nicer system. We'd not have issues such
>> as the current, and we'd be one less item in the pocket of a mega-corp.
>> (You can rank those as you will :)
>>
>> Initially when this can up (a long time ago) Andrew and Tom discussed
>> whether we could import the history here into the forum. I think that's
>> unnecessary. We can still access the history here (until such a day as
>> Google takes it away) at worst -- but, rather, if we can get an archive we
>> could import it into read-only Datasette instance[0] — and that would
>> likely be good enough.
>>
>> Can we move now?
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> [0]: I'd happily do this.
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com
>> 
>> .
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk
>> 
>> .
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJwKpyTSfF51C6ejog0xMd_6s-DofOUT4yaTeWmoc5SEiTY8jQ%40mail.gmail.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKSKe7ZDDwiaBpKtsU0z582K482PFsSpNfTLSvb2B-L95A%40mail.gmail.com.

Re: Integrate dj-database-url into Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Carlton,

Responses inline below:

On Mon, Nov 28, 2022, 2:40 AM Carlton Gibson 
wrote:

> Hi Raphael, thanks for picking this up.
>
> Looking at the history here, particularly the discussion here
> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
> but there are others, the reason this hasn't already happened is that if
> we're going to merge this into core it would be nice (required?) to handle
> extra cases than (to paraphrase) "just what Heroku expects".
>
> It doesn't look like anyone has sat down to spec out exactly what that
> means, but there seem to be plenty of thoughts in the discussion.  ... 樂
>
> JKM's comment on the thread there is representative of the general
> thought:
>
> > 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.
>

Isn't this already a more full solution insofar as it supports setting
CACHES as well? This may or may not be correct, but I read the history a
little differently, more that "life happens" and no one quite found the
energy to push the current solution over the finish line (I empathize
completely!).

The trouble with merging a suboptimal solution is that once it's in, it's *very
> hard* to change. We have the whole API stability policy to contend with
> (and rightly so).
> We bring in a half-baked solution; likely "recommend" it (for some value
> of that) and then face a long stream of difficult adjustments whilst we try
> and accommodate the necessary adjustments.
>

I agree 100%, and I feel like we can and will take this into consideration
sufficiently as we refine the current solution, if we continue down this
path.

 Given that dj-database-url is stable, a single line install, and (most
> importantly) not being developed to try and accommodate the issues that
> stopped it just being merged into core already, I think it should continue
> to live as a third-party package.
>
> The place for the development to happen is in dj-database-url or a
> successor package. (The first step would be a Roadmap drawn from the
> historical discussion.)
> Once (if) that gets to the point where it clearly addresses the 90% of
> needs, then there's a case for adding it to core. I don't think we can just
> push forward given that nothing changed in the last few years.
>

Could you (or others) provide some examples of the needs this solution
doesn't address (not necessarily complete, just to give an idea)?

Many thanks,
Tobias

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.com.

Re: Potential way forward for DATABASE_URL

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Raphael,

Thanks for taking this on.

Starting with a limited scope seems like a good idea to me.

A couple other things I like about this approach:

- It tackles cache URLs at the same time (it makes sense for them to mirror
one another, IMO).
- No implicit usage of DATABASE_URL, but as you said it still supplies an
easily searchable answer for "Django DATABASE_URL."

Cheers,
Tobias

On Sun, Nov 27, 2022, 2:40 PM Raphael G  wrote:

> Some base industry background. It's a pretty common convention to share
> credentials in environment variables. For many PaaS, it's common to use
> connection URLs to do so. So DATABASE_URL will have a URL like
> postgres://my_user:mypassword@somedomain/database stuffed into a single
> environment variable.
>
> Django expects a configuration dictionary for its drivers. So what do
> people do? People install django-database-url, and pass in the string
> into that library (or rather, the library will read a blessed environment
> variable). Absent that they'll need to manually parse out the information
> and build the configuration dictionary. So if you just have Django time
> to futz around with urlparse
>
> There have been some discussions about how to make this better, including:
>
>- adopting dj-database-url as an "official django project" via DEP 7
>
> 
>- instead adopt a behavior where Django will automatically handle a
>string as an alternative to a configuration dictionary
> (this is discussed in
>the first link as PR 10786)
>- Integrate dj-database-url but expand on it a bit to also help with
>cache configuration, and have backends handle URL parsing
>
> 
>
> These haven't seen much movement in the past couple of years. A comment in
> one of these e-mail threads:
>
> > 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.
>
> dj-database-url takes something from an environment variable and provides
> a configuration dictionary. There's this feeling that having Django
> directly accept a string would feel more natural and correct. There are
> also other libraries like dsnparse, and people proposing things like
> adding a DSN name into settings.
>
> I think of all the options, the third option (the proposal by Tom Forbes)
> is a very good option. What it looks like in practice is the addition of
> the following:
>
>- the ability for database backends to register protocol names for
>URLs, so that postgres://localhost:5432 will properly map to the
>django.db.backends.postgresql backend, but people can show up with
>their own mappings.
>- A configure_db(url) function, that will return a configuration
>dictionary meant for DATABASES
>- A similar configure_cache(url) function that will give cache
>configuration dictionaries meant for CACHES
>
> A thing that is notably absent here is any blessing of DATABASE_URL. You
> have to do
>
> DATABASES = {
> 'default': configure_db(os.environ['DATABASE_URL'])
> }
>
> yourself. It's not "ideal" in that you don't magically get behavior from
> your URLs, but that also means you're just doing something in a
> straightforward way that should be easy to debug with some print statements
> when needed. It feels way less likely for this to be a major design miss.
>
> The motivating examples for the two above being supported is that Heroku
> will provide DATABASE_URL and REDIS_URL.
>
> The nice thing about this solution is that it doesn't block future design
> space. We get a configuration dictionary that matches the existing
> functionality, because the added API is simple it's easy for people to
> inspect the results, and of course it doesn't preclude people from keeping
> on with their existing solutions. There isn't even an assumed usage of
> DATABASE_URL like with dj-database-url! Mostly magic free.
>
I tried to rebase the PR
>  
> including
> the above functionality from a couple years ago, and added some basic
> documentation. This doesn't try and convince users to use this, but I
> believe the usage would be sufficient for simple cases.
>
> So my ask here: how do people feel about moving forward with this limited
> scope? Previous discussions talked about wanting a larger scope for it to
> get merged into core. I believe that instead targetting a smaller scope
> means we can at least provide a workable answer to the DATABASE_URL question
> in the near term. And when consensus coalesces around a good overall answer
> to settings, the actual URL parsing logic will already be present and 

Re: #21978 include production-ready web server

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Pete,

A pluggable backend sounds like a good idea.

Regarding DJANGO_ENV, why not ship the template with two settings files and
use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
environment variable?

Maybe that would be controversial too, I'm not sure, but perhaps less so
than introducing a new paradigm? In any event, perhaps a pluggable backend
would allow everyone to be happy, or very nearly so... 

To be clear, I'm fully in support of this, no matter how it ends up.
Providing a decent production-capable server and some sane
settings/configuration defaults for people to work from -- rather than
having to scour the documentation for every mention of a production
environment and figure out how to make those changes by hand -- will be a
big win IMO. As it stands, first time users might reasonably assume they
should use Apache to deploy to production (maybe they should, I'm not
sure...but I haven't seen it done in over a decade):

"We’ve included this with Django so you can develop things rapidly, without
having to deal with configuring a production server – such as Apache –
until you’re ready for production."

https://docs.djangoproject.com/en/4.1/intro/tutorial01/

Cheers,
Tobias

On Sat, Oct 29, 2022, 7:15 PM Peter Baumgartner 
wrote:

>
>
> On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
> wrote:
>
>> Thanks for the thorough review Florian! Some comments inline...
>>
>> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
>> wrote:
>>
>>> Hi Pete,
>>>
>>> this does look interesting. And I agree that this is something that
>>> would be nice to have in core in one form or another. That said I think we
>>> have to do it iteratively (ie in smaller parts) and evaluate along the way.
>>>
>>
>> Agreed. I think adding the additional settings with some sort of
>> production switch is the least obtrusive place to start.
>>
>>
>>>
>>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary widely).
>>>
>>
>> Production environments do vary widely, but I don't think that should
>> stop us from providing defaults that are one-size-fits-most. startproject
>> already does this and users are welcome to adjust it how they see fit.
>>
>>
>>>
>>>  * As soon as health checks check something aside from simply returning
>>> a 200 status code I'd want to be able to limit access to them
>>>
>>
>> Yep, that seems reasonable. Although depending on the level of failure,
>> you may not be able to log in to see them. Starting with just a view that
>> responds with a 200 is reasonable.
>>
>>
>>>  * I like my dev env to be as close as possible to production so I
>>> usually also use whitenoise in dev. I had to many times where dev worked
>>> and whitenoise in prod failed then :D
>>>
>>
>> Also a good point... I'll add that.
>>
>>
>>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>> from time to time
>>>
>>
>> I'm open to other suggestions here, but am kind of in the same boat.
>> There may be times when you briefly want DEBUG=True in a non-public
>> deployed environment or DEBUG=False in a development environment.
>> Overloading that makes those scenarios a challenge.
>>
>>
>>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>>> variables that leak down the whole process-tree. django-environ does
>>> support this; that said there are other options like dynaconf which also
>>> support hashicorp vault which is a massive plus imo. Just being able to
>>> utilize vault for free from every django application out there would be
>>> stellar.
>>>
>>
>> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
>> about dynaconf which does a lot of the same things. I would love to see
>> Django adopt a split between "settings" (which I see as things that don't
>> change across environments) and "configuration" (things that you set per
>> environment). I did switch to django-environ's FileAwareEnv [2] which
>> allows loading from files, but not in the yaml./toml sense. I didn't go all
>> in here because I felt like it was a more controversial stance and at the
>> end of the day, you probably still need to support environment variables
>> because many (most?) PaaS providers don't have support for files like that.
>>
>> With the goal of getting something merged into Django eventually, I felt
>> like environment variables were the lowest bar. We have precedence for
>> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
>> think a more full-featured library like dynaconf would make it harder to
>> push some of this upstream? Users that want to use dynaconf or goodconf or
>> whatever can still edit their settings and use those like they do today.
>>
>> [1] https://github.com/lincolnloop/goodconf
>> [2]
>> https://django-environ.readthedocs.io/en/latest/tips.html#docker-style-file-based-variables
>>
>

Re: Proposal: Add An in-memory data storage backend in Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi,

I also may be missing some context, but is this the mentioned package?
https://github.com/waveaccounting/dj-inmemorystorage

I have not used it, but it looks like a useful tool to have!

Tobias


On Thu, Oct 20, 2022 at 7:50 PM David Sanders 
wrote:

> Hi,
>
> I may be missing some context here but is this something distinctly
> different from setting SQLite to use in-memory storage [1]? 樂
>
> [1] https://www.sqlite.org/inmemorydb.html
>
> David
>
> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
> pa...@melchiorre.org> wrote:
>
>> Hi all,
>>
>> there is a package that provide in-memory data storage backend, but it's
>> now abandoned.
>>
>> Having support for in-memory data storage could be very useful for Django
>> itself and furthermore it would involve adding a small code with tests that
>> do not justify the creation of a fork of that old package.
>>
>> We are talking about this during the sprints at DjangoCon US 2023 in San
>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on
>> this list.
>>
>> What do you think about adding an in-memory data storage backend directly
>> in the Django core?
>>
>> Ciao,
>> Paolo
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com
>> 
>> .
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKRiEsi7BqaNUJGFWNYqpfP3Cq8TVx3fQYuuYp9ii-injw%40mail.gmail.com.

Re: Blocking disposable or temporary email addresses

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Yonas,

Thanks for sharing this list. Even so, in my opinion, this feature lives
best outside of Django where it can be appropriately customized as needed
for a given project.

I hope this helps.

Best,
Tobias


On Wed, May 11, 2022, 6:46 PM Yonas 
wrote:

>
> Would syncing the block list from repos like
> https://github.com/disposable-email-domains/disposable-email-domains
> (actively maintained since 2014) ease the burden of updating the list?
> On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote:
>
>> On Wed, May 11, 2022 at 2:21 PM Yonas 
>> wrote:
>>
>>> What does the community think about adding a feature to Django where
>>> disposable or temporary emails are not accepted during account registration?
>>
>>
>> I used to try to do this in my django-registration package, but
>> eventually gave up on it because maintaining an up-to-date list of all
>> possible domains and other patterns was not feasible. I expect the same
>> would be true with Django — it would require frequent updates to the list
>> of domains/patterns to block, and people would complain that the updates
>> weren’t fast enough, because Django only releases once a month (and that’s
>> assuming updates to the blocked email list would be considered for
>> inclusion in the monthly bugfix releases, rather than only at feature
>> release updates).
>>
>> So I expect this isn’t something Django could or should do.
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b669801b-f695-49c2-9d04-2ff7db74dc58n%40googlegroups.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%40mail.gmail.com.

Re: Improvements to the startproject template

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Tim,

Thanks for taking this on!

Needless to say, I'm all in favor of including a default 'users' app.
Adding one (as has long been recommended by the docs) is a task best
automated.

I've definitely had the "no the other folder" conversation more than enough
times myself. Personally I think I prefer the orderliness of nesting
everything under a single Python package that is the project name, but I'm
not sure how to do that and solve the "two folders with the same name"
problem. In any event, I support whatever the consensus is.

Cheers,
Tobias



On Mon, Apr 18, 2022, 1:17 PM Tim Allen  wrote:

> Greetings, friends!
>
> I've issued a PR that makes two changes to the `startproject` template:
>
>- instead of putting configuration files such
>as `settings.py`, `wsgi.py`, and the
>root `urls.py` in `my_project/my_project`, they are created
>in `my_project/config`
>- start the project with a custom User model app, `users`
>
> Over the years, I've taught or tutored over 100 Djangonauts starting their
> first project. Having to distinguish between two directories with the same
> name is a constant pain point in the teaching process - "cd into my_project
> ... no, the other one!"
>
>
>- The `config` option seemed to be the consensus from this thread in
>the forum: Django New Project Structure/Name - Using Django - Django
>Forum (djangoproject.com)
>
>- Ticket: https://github.com/django/django/pull/15609
>
> It is sometimes better to show rather than tell, so following our own
> documentation and including a custom User model with the initial project
> template reinforces the best practice that we explicitly point out in the
> documentation.
>
>
>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) –
>Django (djangoproject.com)
>
>- Avoids ever having this come up again:
>
> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>
> Here's a link to the PR: https://github.com/django/django/pull/15609
>
> My apologies for not starting with a discussion first. I'm an infrequent
> contributor to the Django codebase!
>
> Regards,
>
> Tim
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/33cb49d0-2469-47c0-920e-9501245c5a27n%40googlegroups.com
> 
> .
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKSKKs08Z3rts4Xeewh1fxNkbmt8LyqqHfofAUF0xs0oAg%40mail.gmail.com.