Re: GSoC 2020 Proposal for ModelStates in Migrations

[charettes]

Thanks for the examples Sanskar.

I think the mapping should be kept ProjetState instances and invalidated 
when state alterations are performed. In an ideal world I think that 
ProjectState should have methods mapping to all Operation subclasses 
state_forwards and these state_forwards methods should only proxy 
ProjectState methods.

The CreateModel.state_forwards method is a good example of that[0]; it 
calls into ProjectState.add_model where all the storage and cache 
invalidation logic is encapsulated[1]. If ProjectState had methods such as 
rename_model, alter_field, and such it would make it easily testable in 
isolation and allow it to maintain it's related object cache, or mapping as 
you call it, more easily.

Simon

[0] 
https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/operations/models.py#L80-L87
[1] 
https://github.com/django/django/blob/421622548060499881df9966b7a352bce63901cd/django/db/migrations/state.py#L91-L95

Le jeudi 26 mars 2020 16:01:05 UTC-4, Sanskar Jaiswal a écrit :
>
> Hi Simon
>
> Taking advice into account, I have made some more changes to my proposal 
> . 
> Please check it out and criticize it wherever you think I could improve it 
> as always. :)
>
> Also, could you kindly give some kind of idea as to when the new mappings 
> should be populated? I think it makes sense to do so whenever we run 
> makemigrations. Do you have a better idea?
>
> Thanks!
> Kind Regards
> Sanskar
>
> On Thu, Mar 26, 2020 at 6:05 AM charettes > 
> wrote:
>
>> Thanks Sanskar, this iteration is much better.
>>
>> Now that you have a bit more details about your proposed changes 
>> breakdown I'd give a bit more examples of what a particular operation 
>> currently looks like now and you plan to change it. For example, you could 
>> describe how an AlterField operation currently alter the state/database 
>> forwards with the involved function calls and how you plan to changes 
>> things.
>>
>> Detailing a bit more how the related lookups cache invalidation would be 
>> busted and populated when a specific operation is performed would go a long 
>> way to support your proposal.
>>
>> To summarize, a few examples of what you have in mind and how things 
>> would interact together would be appreciated. This is a quite a complex 
>> problem to solve so a solid initial plan and understanding of the problem 
>> will make a huge difference down the road.
>>
>> Cheers,
>> Simon
>>
>> Le mercredi 25 mars 2020 19:10:40 UTC-4, Sanskar Jaiswal a écrit :
>>>
>>> Hey Simon
>>>
>>> I have made some changes to the proposal. I kindly request you to take a 
>>> look at it and give any feedback you can :)
>>>
>>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>>
>>> Kind Regards 
>>> Sanskar
>>>
>>>
>>>
>>> On Wed, 25 Mar 2020 at 23:57, charettes  wrote:
>>>
 Are you thinking about the Operation.state_forwards logic? I guess it 
 would make it easier to test state alterations in isolation but I don't 
 think it's necessary for this already large project.

 Cheers,
 Simon

 Le mercredi 25 mars 2020 06:05:22 UTC-4, Sanskar Jaiswal a écrit :
>
> Hey Simon
>
> Just so that I am more clear, is it favourable to move all logic that 
> ModelOperations and FieldOperations implement right now to ProjectState 
> and 
> ModelState?
>
> Kind regards
> Sanskar
>
> On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal  
> wrote:
>
>> Hey Simon,
>>
>> Thank you for your feedback! It helps a lot. I shall look into your 
>> doubts right now, and edit my proposal accordingly.
>>
>> Kind regards
>>
>> Sanskar
>>
>> On Tue, Mar 24, 2020 at 3:37 AM charettes  wrote:
>>
>>> Hello Sanskar,
>>>
>>> Thank you for your submission, from a quick look it seems to be 
>>> heading in the right direction.
>>>
>>> Would it be possible to break the large overview section into more 
>>> granular sections where you describe how you roughly plan to tackle 
>>> each of 
>>> the point mention?
>>>
>>> I personally have doubts about your desire to make minimal change to 
>>> the schema editor and offload the logic to database_forwards instead of 
>>> the 
>>> other way around. That doesn't seem to be in line with a future 
>>> deprecation 
>>> of support for direct model passing. I'd much rather see us move all 
>>> methods to (project_state, model_state, *other_state, 
>>> **other_fields_and_flags) signatures and provide helpers to help 
>>> third-party backends migrate (e.g. a method decorator that renders 
>>> mode) 
>>> then embedding logic for both paths in the schema editor and adding 
>>> schema 
>>> specific logic to Operation.database_forwards.
>>>
>>> Simon
>>>
>>> Le lundi 23 mars 

Re: GSoC Mentors

[Tom Forbes]

Happy to help any way I can (very time constrained in the near future, but 
that should ease off). 

I think sharing the burden as a group is a great idea.

On Wednesday, 25 March 2020 08:43:49 UTC, Carlton Gibson wrote:
>
> Hi all. 
>
> We're reaching the end of the application period for GSoC. 
>
> In order to know how many students we might accept, we need to know how 
> many prospective mentors we have. 
>
> This falls into two kinds of job: 
>
> 1. General project management help: communicating with students to help 
> them set a schedule and a rhythm, and make sure they're able to make 
> progress. (The hope is they're self motivated but...) 
>
> 2. More technical input. For this I'm thinking particularly about the 
> migrations framwork (Markus, Simon, Shai, Andrew, ...) but *experienced 
> hands* with knowledge of the internals: your input would be invaluable 
> here. 
>
> The forum seems to be working well, and it's a good format for this kind 
> of thing, so I want to aim to focus the discussion there. 
>
> I'd like to share the mentoring as a group. We'd need to assign specific 
> mentors but I don't see why it can't be a group thing. 
>
> If you could hang out a bit on the forum (mainly for task 1) and/or offer 
> technical input, which you might be doing already/anyway (for task 2) then 
> that would be a super contribution. 
>
> Please let me know if you'd be willing to help mentor. 
>
> Thanks
>
> Kind Regards,
>
> Carlton
>
>

-- 
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/447df6b5-5bf2-45a2-985d-59a239c285b2%40googlegroups.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Tom Forbes]

Ahh, interesting! I think I can help mentoring, I’ll leave a reply in the 
official thread 

> On 26 Mar 2020, at 11:40, Carlton Gibson  wrote:
> 
> Hi Tom.
> 
> (I was wondering if you might fancy mentoring on this project? )
> 
> On Thursday, 26 March 2020 12:35:34 UTC+1, Tom Forbes wrote:
> > incompatible in macOS due to a recent update
> 
> Can you elaborate on this a bit? How has a recent update made forking 
> incompatible on MacOS?
> 
> macOS has deprecated the fork launch method, to be removed in a future 
> version.
> 
> Python 3.8+ then swaps the default launch method to spawn, so on Python 3.8+ 
> we no longer have parallel test running on the mac.
> 
> (For now, fork still actually works, so you can `set_start_method()` to work 
> around this, but...)
> 
> Kind Regards,
> 
> Carlton
> 
> 
> --
> 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/e5a1464f-553c-4990-8dd2-6c4086e329c4%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/6BEF04AA-F616-46E9-85F8-BD8CF8C38533%40tomforb.es.


signature.asc
Description: Message signed with OpenPGP

Re: GSoC Mentors

[ramya kurapati]

I want to take on a project and start contributing my part to django but I 
have no idea where to start. If anyone can help me, that would be great...
thanks a lot.

On Wednesday, March 25, 2020 at 2:13:49 PM UTC+5:30, Carlton Gibson wrote:
>
> Hi all. 
>
> We're reaching the end of the application period for GSoC. 
>
> In order to know how many students we might accept, we need to know how 
> many prospective mentors we have. 
>
> This falls into two kinds of job: 
>
> 1. General project management help: communicating with students to help 
> them set a schedule and a rhythm, and make sure they're able to make 
> progress. (The hope is they're self motivated but...) 
>
> 2. More technical input. For this I'm thinking particularly about the 
> migrations framwork (Markus, Simon, Shai, Andrew, ...) but *experienced 
> hands* with knowledge of the internals: your input would be invaluable 
> here. 
>
> The forum seems to be working well, and it's a good format for this kind 
> of thing, so I want to aim to focus the discussion there. 
>
> I'd like to share the mentoring as a group. We'd need to assign specific 
> mentors but I don't see why it can't be a group thing. 
>
> If you could hang out a bit on the forum (mainly for task 1) and/or offer 
> technical input, which you might be doing already/anyway (for task 2) then 
> that would be a super contribution. 
>
> Please let me know if you'd be willing to help mentor. 
>
> Thanks
>
> Kind Regards,
>
> Carlton
>
>

-- 
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/92972211-e4c4-41e5-b7bd-9cb3115a0322%40googlegroups.com.

Re: [GSoC 2020] Secrets Manager Proposal

[Abhirav Dilip Kariya]

Hello everyone,


As the deadline for final proposals is coming up. I would like some 
feedback on my proposal.

Here is the link to my proposal: GSoC Proposal 


Link to Prototype Gist 

Link to Prototype 

Thanks in advance,
Abhirav Dilip Kariya

On Saturday, 21 March 2020 10:36:46 UTC-4, Abhirav Dilip Kariya wrote:
>
> Hello everyone,
>
> I’ve submitted my proposal draft for GSoC for the 'Secrets Manager' idea 
> listed at Django's Wiki for GSoC 2020 
> . 
>
> Here is the link to my proposal: GSoC Proposal 
> 
>
> Link to Prototype Gist 
> 
> Link to Prototype 
>
>
> Please let me know if you get the time to go through it and have any 
> feedback for me.
>
>
> Thanks in advance,
> Abhirav Dilip Kariya
>

-- 
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/f88e01d0-4e9e-4e02-8a94-0df590cbc3c6%40googlegroups.com.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Sanskar Jaiswal]

Hi Simon

Taking advice into account, I have made some more changes to my proposal
.
Please check it out and criticize it wherever you think I could improve it
as always. :)

Also, could you kindly give some kind of idea as to when the new mappings
should be populated? I think it makes sense to do so whenever we run
makemigrations. Do you have a better idea?

Thanks!
Kind Regards
Sanskar

On Thu, Mar 26, 2020 at 6:05 AM charettes  wrote:

> Thanks Sanskar, this iteration is much better.
>
> Now that you have a bit more details about your proposed changes breakdown
> I'd give a bit more examples of what a particular operation currently looks
> like now and you plan to change it. For example, you could describe how an
> AlterField operation currently alter the state/database forwards with the
> involved function calls and how you plan to changes things.
>
> Detailing a bit more how the related lookups cache invalidation would be
> busted and populated when a specific operation is performed would go a long
> way to support your proposal.
>
> To summarize, a few examples of what you have in mind and how things would
> interact together would be appreciated. This is a quite a complex problem
> to solve so a solid initial plan and understanding of the problem will make
> a huge difference down the road.
>
> Cheers,
> Simon
>
> Le mercredi 25 mars 2020 19:10:40 UTC-4, Sanskar Jaiswal a écrit :
>>
>> Hey Simon
>>
>> I have made some changes to the proposal. I kindly request you to take a
>> look at it and give any feedback you can :)
>>
>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>
>> Kind Regards
>> Sanskar
>>
>>
>>
>> On Wed, 25 Mar 2020 at 23:57, charettes  wrote:
>>
>>> Are you thinking about the Operation.state_forwards logic? I guess it
>>> would make it easier to test state alterations in isolation but I don't
>>> think it's necessary for this already large project.
>>>
>>> Cheers,
>>> Simon
>>>
>>> Le mercredi 25 mars 2020 06:05:22 UTC-4, Sanskar Jaiswal a écrit :

 Hey Simon

 Just so that I am more clear, is it favourable to move all logic that
 ModelOperations and FieldOperations implement right now to ProjectState and
 ModelState?

 Kind regards
 Sanskar

 On Tue, 24 Mar 2020 at 04:20, Sanskar Jaiswal 
 wrote:

> Hey Simon,
>
> Thank you for your feedback! It helps a lot. I shall look into your
> doubts right now, and edit my proposal accordingly.
>
> Kind regards
>
> Sanskar
>
> On Tue, Mar 24, 2020 at 3:37 AM charettes  wrote:
>
>> Hello Sanskar,
>>
>> Thank you for your submission, from a quick look it seems to be
>> heading in the right direction.
>>
>> Would it be possible to break the large overview section into more
>> granular sections where you describe how you roughly plan to tackle each 
>> of
>> the point mention?
>>
>> I personally have doubts about your desire to make minimal change to
>> the schema editor and offload the logic to database_forwards instead of 
>> the
>> other way around. That doesn't seem to be in line with a future 
>> deprecation
>> of support for direct model passing. I'd much rather see us move all
>> methods to (project_state, model_state, *other_state,
>> **other_fields_and_flags) signatures and provide helpers to help
>> third-party backends migrate (e.g. a method decorator that renders mode)
>> then embedding logic for both paths in the schema editor and adding 
>> schema
>> specific logic to Operation.database_forwards.
>>
>> Simon
>>
>> Le lundi 23 mars 2020 12:59:55 UTC-4, Sanskar Jaiswal a écrit :
>>>
>>> Hey everyone,
>>>
>>> Here is my proposal for GSoC. My project is based upon making use of
>>> ModelState during the migrated phase of the project, rather than 
>>> rendering
>>> fake Models.
>>>
>>> https://gist.github.com/aryan9600/b1c2eaf445006c17e02e7677cf1098d5
>>>
>>> Feedback and criticism is highly appreciated.
>>>
>>> Thanks!
>>> Kind regards
>>> Sanskar
>>>
>> --
>> 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-d...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com
>> 
>> .
>>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django 

Re: GSoC Mentors

[Adam Johnson]

Happy to help mentor in both realms! 珞

On Thu, 26 Mar 2020 at 15:59, Carlton Gibson 
wrote:

> Hi David. Thanks.
>
> That makes a few folks that have put their hands up so 
>
> On Thu, 26 Mar 2020 at 13:47, David Smith  wrote:
>
>> Hi Carlton,
>>
>> I'm happy to help out with 1), if you think I would be helpful.
>>
>> I will not be of much help with 2) :-)
>>
>> David
>>
>> --
>> 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/da593286-005f-4a1a-8359-cf8210a1a975%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/CAJwKpyT2EXJ39Y-mdn7OscPwcACnvh_wt33GX08jsRpLFXBSdw%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM2fh1vZT6PNgQ0mOjGVb875jA4NrS4NVdK9JpCHNst5sw%40mail.gmail.com.

Re: AUTH_USER_MODEL refers to model 'restro_app.CustomUser' that has not been installed

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Thu, 26 Mar 2020 at 18:12, Dhruv Agarwal  wrote:

> I suppose your problem is that you haven't configured your retro_app
>
> So,You first need to add "retro_app" in list of installed_apps in
> settings.py.
>
> Correct me if I understand the issue wrongly.
>
> --
> 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/8c13a393-cd14-4489-afff-2d7277760683%40googlegroups.com
> .
>


-- 
Adam

-- 
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/CAMyDDM2scU_JrzLiqfWDBcZNsN%3D8N4euikBxBLRTwR-tABMzzQ%40mail.gmail.com.

AUTH_USER_MODEL refers to model 'restro_app.CustomUser' that has not been installed

[Dhruv Agarwal]

I suppose your problem is that you haven't configured your retro_app

So,You first need to add "retro_app" in list of installed_apps in settings.py.

Correct me if I understand the issue wrongly.

-- 
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/8c13a393-cd14-4489-afff-2d7277760683%40googlegroups.com.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

[James Bennett]

I'm also in the "I don't think this should be allowed" camp. People
who really need it can set up their own validator easily enough, and I
worry about the security implications of supporting non-standard
behavior in something as crucial as hostname validation -- Django's
been bitten by that sort of thing several times in the past.

-- 
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/CAL13Cg-k6CGLZo9o%3DRG4LpGj5CbP57ayeGyBrKYXa7SPx07%2BWg%40mail.gmail.com.

GSOC Proposal: 2FA

[Rohit Jha]

Hi,

Here is my proposal for GSoCon 2FA

https://docs.google.com/document/d/1f-9hOYHZ9rzLH7UEzdPmVi1n4jQJ92gDwYpqef1ZYMk/edit?usp=sharing

Feedback and criticism is highly appreciated.
Thanks & Regards 

-- 
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/73929c8c-5643-4134-90a3-ceb7094aadb9%40googlegroups.com.

AUTH_USER_MODEL refers to model 'restro_app.CustomUser' that has not been installed

[Kushal Neupane]

D:\Development\Backup\2\restroapp>python manage.py runserver
Watching for file changes with StatReloader
Exception in thread django-main-thread:
Traceback (most recent call last):
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\apps\registry.py", line 155, in 
get_app_config
return self.app_configs[app_label]
KeyError: 'restro_app'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\contrib\auth\__init__.py", line 
156, in get_user_model
return django_apps.get_model(settings.AUTH_USER_MODEL, 
require_ready=False)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\apps\registry.py", line 205, in 
get_model
app_config = self.get_app_config(app_label)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\apps\registry.py", line 162, in 
get_app_config
raise LookupError(message)
LookupError: No installed app with label 'restro_app'.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 916, in 
_bootstrap_inner
self.run()
  File "C:\Program Files (x86)\Python36-32\lib\threading.py", line 864, in 
run
self._target(*self._args, **self._kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\autoreload.py", line 53, 
in wrapper
fn(*args, **kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\commands\runserver.py",
 
line 109, in inner_run
autoreload.raise_last_exception()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\autoreload.py", line 76, 
in raise_last_exception
raise _exception[1]
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\core\management\__init__.py", 
line 357, in execute
autoreload.check_errors(django.setup)()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\autoreload.py", line 53, 
in wrapper
fn(*args, **kwargs)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\apps\registry.py", line 122, in 
populate
app_config.ready()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\contrib\admin\apps.py", line 24, 
in ready
self.module.autodiscover()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\contrib\admin\__init__.py", line 
26, in autodiscover
autodiscover_modules('admin', register_to=site)
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\utils\module_loading.py", line 
47, in autodiscover_modules
import_module('%s.%s' % (app_config.name, module_to_search))
  File "C:\Program Files (x86)\Python36-32\lib\importlib\__init__.py", line 
126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 994, in _gcd_import
  File "", line 971, in _find_and_load
  File "", line 955, in _find_and_load_unlocked
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in 
_call_with_frames_removed
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\contrib\auth\admin.py", line 6, 
in 
from django.contrib.auth.forms import (
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\contrib\auth\forms.py", line 20, 
in 
UserModel = get_user_model()
  File "C:\Program Files 
(x86)\Python36-32\lib\site-packages\django\contrib\auth\__init__.py", line 
161, in get_user_model
"AUTH_USER_MODEL refers to model '%s' that has not been installed" % 
settings.AUTH_USER_MODEL
django.core.exceptions.ImproperlyConfigured: AUTH_USER_MODEL refers to 
model 'restro_app.CustomUser' that has not been installed

-- 
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/8f58a04b-7cc1-4d81-bcfb-01f0b6f04b52%40googlegroups.com.

Re: GSoC Mentors

[Hasnat Jutt]

Hi Gibson,

I am available and willing to help in task 1 (General Project
Management Help).

On Thu, Mar 26, 2020 at 5:47 PM David Smith  wrote:

> Hi Carlton,
>
> I'm happy to help out with 1), if you think I would be helpful.
>
> I will not be of much help with 2) :-)
>
> David
>
> --
> 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/da593286-005f-4a1a-8359-cf8210a1a975%40googlegroups.com
> .
>


-- 
Regards

Hasnat Aslam
Researcher
+923228083867
hhasnat44...@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/CAPrLfueLOeXh2JyajbNCNUOOUGXnTurNtY-%3D7tJuhxUJ5E8mLQ%40mail.gmail.com.

Re: GSoC Mentors

[Carlton Gibson]

Hi David. Thanks.

That makes a few folks that have put their hands up so 

On Thu, 26 Mar 2020 at 13:47, David Smith  wrote:

> Hi Carlton,
>
> I'm happy to help out with 1), if you think I would be helpful.
>
> I will not be of much help with 2) :-)
>
> David
>
> --
> 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/da593286-005f-4a1a-8359-cf8210a1a975%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/CAJwKpyT2EXJ39Y-mdn7OscPwcACnvh_wt33GX08jsRpLFXBSdw%40mail.gmail.com.

[GSOC 2020] Proposal for supporting the parallel test runner on Windows, and Oracle

[Abhijeet Viswa]

Hey folks,

I'd highly appreciate it if you guys could go through my GSoC prposal for 
adding supporting the parallel test runner on Windows, and Oracle.
Django Forum Post: 
https://forum.djangoproject.com/t/gsoc-2020-my-proposal-for-a-parallel-test-runner/1518/3
GitHub Gist:  
https://gist.github.com/abhijeetviswa/08c23388ae3d317621e23b947594b9f3

Thanks. :) 


-- 
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/4da18b6d-4e9c-4035-a0f6-33e68c69aa12%40googlegroups.com.

GSoC Mentors

[David Smith]

Hi Carlton,

I'm happy to help out with 1), if you think I would be helpful. 

I will not be of much help with 2) :-) 

David

-- 
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/da593286-005f-4a1a-8359-cf8210a1a975%40googlegroups.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Abhijeet Viswa]

Hey,

Since Python 3.8, the default method for the multiprocessing module is
spawn for Mac OS.

On Thu, 26 Mar 2020 at 17:05, Tom Forbes  wrote:

> > incompatible in macOS due to a recent update
>
> Can you elaborate on this a bit? How has a recent update made forking
> incompatible on MacOS?
>
> Tom
>
> On 23 Mar 2020, at 19:22, Ahmad A. Hussein 
> wrote:
>
> Django's parallel test runner works through forking processes, making it
> incompatible on Windows by default and incompatible in macOS due to a
> recent update. Windows and macOS both support spawn and have it enabled by
> default. Databases are cloned for each worker.
>
> To switch from fork to spawn, state setup will be handled by spawned
> processes instead of through inheritance via fork. Worker’s connections to
> databases can still be done through get_test_db_clone_settings which
> changes the names of databases assigned to a specific worker_id; however,
> SQLite's cloning method is incompatible with spawn.
>
>
> SQLite’s cloning method relies on it both being in-memory and fork as when
> we fork the main process, we retain SQLite's in-memory database in the
> child process. The solution is to get a SQL dump of the database and throw
> it into the target cloned databases. This is also the established standard
> in handling MySQL’s cloning process. Both Postgresql's and MySQL's cloning
> methods are independent of fork or spawn and won't require any modification.
>
> Oracle has not been implemented in the parallel test runner originally
> even on Linux and I propose to extend support to Oracle as well in my
> proposal. I want to confirm if there is significant support behind this as
> a feature or not before I commit to writing a specification, but as a
> summary it is definitely possible as the work collaborated on by Aymeric
> Augustin and Shai Berger show that cloning CAN be done through multiple
> ideas. The reason why it's a headache is that Oracle does not support
> separate databases under a single user- unlike our other supported
> databases, so we can't clone databases without introducing another user.
> Some methods may also need to be rewritten to accommodate for the Oracle
> backend, but that isn't an issue. I've glossed over writing out a schedule
> or a more detailed abstract as I I'm mainly posting here to see if there is
> indeed support for the Oracle proposal and to make sure I am not missing
> any details in regards to adapting the current parallel test runner to work
> through spawn. Let me know what you think.
>
> Regards,
> Ahmad
>
> --
> 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/317f67c6-4b23-483f-ada5-9bdbb45d0997%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/322804F5-F44F-4EF8-AF33-C460EC509915%40tomforb.es
> 
> .
>


-- 
Abhijeet

-- 
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/CAP1-Yrp47LJrFxcfp_-ZDQAJiAmvR8SecjTPN-Vc%2B4vwhz%3DkeA%40mail.gmail.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Carlton Gibson]

Hi Tom. 

(I was wondering if you might fancy mentoring on this project? )

On Thursday, 26 March 2020 12:35:34 UTC+1, Tom Forbes wrote:
>
> > incompatible in macOS due to a recent update
>
> Can you elaborate on this a bit? How has a recent update made forking 
> incompatible on MacOS?
>

macOS has deprecated the fork launch method, to be removed in a future 
version. 

Python 3.8+ then swaps the default launch method to spawn, so on Python 
3.8+ we no longer have parallel test running on the mac.

(For now, fork still actually works, so you can `set_start_method()` to 
work around this, but...)

Kind Regards,

Carlton

-- 
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/e5a1464f-553c-4990-8dd2-6c4086e329c4%40googlegroups.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Tom Forbes]

> incompatible in macOS due to a recent update

Can you elaborate on this a bit? How has a recent update made forking 
incompatible on MacOS?

Tom

> On 23 Mar 2020, at 19:22, Ahmad A. Hussein  wrote:
> 
> Django's parallel test runner works through forking processes, making it 
> incompatible on Windows by default and incompatible in macOS due to a recent 
> update. Windows and macOS both support spawn and have it enabled by default. 
> Databases are cloned for each worker.
> 
> To switch from fork to spawn, state setup will be handled by spawned 
> processes instead of through inheritance via fork. Worker’s connections to 
> databases can still be done through get_test_db_clone_settings which changes 
> the names of databases assigned to a specific worker_id; however, SQLite's 
> cloning method is incompatible with spawn.  
> 
> 
> SQLite’s cloning method relies on it both being in-memory and fork as when we 
> fork the main process, we retain SQLite's in-memory database in the child 
> process. The solution is to get a SQL dump of the database and throw it into 
> the target cloned databases. This is also the established standard in 
> handling MySQL’s cloning process.
> 
> Both Postgresql's and MySQL's cloning methods are independent of fork or 
> spawn and won't require any modification.
> 
> Oracle has not been implemented in the parallel test runner originally even 
> on Linux and I propose to extend support to Oracle as well in my proposal. I 
> want to confirm if there is significant support behind this as a feature or 
> not before I commit to writing a specification, but as a summary it is 
> definitely possible as the work collaborated on by Aymeric Augustin and Shai 
> Berger show that cloning CAN be done through multiple ideas. The reason why 
> it's a headache is that Oracle does not support separate databases under a 
> single user- unlike our other supported databases, so we can't clone 
> databases without introducing another user. Some methods may also need to be 
> rewritten to accommodate for the Oracle backend, but that isn't an issue.
> 
> I've glossed over writing out a schedule or a more detailed abstract as I I'm 
> mainly posting here to see if there is indeed support for the Oracle proposal 
> and to make sure I am not missing any details in regards to adapting the 
> current parallel test runner to work through spawn. Let me know what you 
> think.
> 
> Regards,
> Ahmad
> 
> -- 
> 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/317f67c6-4b23-483f-ada5-9bdbb45d0997%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/322804F5-F44F-4EF8-AF33-C460EC509915%40tomforb.es.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

[Carlton Gibson]

> By all means add a lenient=False flag which can be turned to True to 
enable lenient parsing...

I don't think we should even allow this. The extra API surface area 
complicates the matter for all users, almost all of whom are never going to 
set the new flag to anything but the default. (Of those that do, how many 
wouldn't really have thought it through/mean it?) 

Folks wanting this can subclass URLValidator. 

C. 

-- 
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/7bc7bd6c-021b-45c2-bc0b-2fad3b2356b6%40googlegroups.com.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

[Florian Apolloner]

Hi Adam,

On Wednesday, March 25, 2020 at 7:27:58 PM UTC+1, Adam Johnson wrote:
>
> I think that would make Florian happy, although it *has* been seven years 
> since his closing comment on the ticket.
>

You should know me better :D No this would not make Florian happy and he is 
still against it. By all means add a lenient=False flag which can be turned 
to True to enable lenient parsing but the defaults should imo stay.

It might be true that for the sole purpose of __displaying__ URLs that an 
underscore will not hurt, but in the greater scheme of things it simply 
does not work:

 * java.net.URI will not parse it: new 
java.net.URI("http://test_host.com;).getHost -> null
 * While you laugh about me mentioning java the more relevant argument is 
that we are going towards a HTTPs world and there you have to play by a 
different set of rules namely CA/Browser Forum Baseline Requirements. These 
requirements require you to follow RFCs (especially RFC 5280) which in turn 
requires subjectAltNames to follow the preferred style of RFC 1034 which 
finally disallows the use of underscores. So for this reason CAs won't 
allow you to issue certs for those hostnames, you can only make those work 
via wildcard certs, which in turn only work for subdomains and not TLDs.

So this limits the usefulness of underscores in URLs to mainly http-only 
sites or sites that went around extra hoops to get it working. In that 
sense I do not see a strong requirement to be lenient in parsing by default.

Cheers,
Florian

-- 
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/e6a7c79d-f53f-4893-bf05-06fa5475f915%40googlegroups.com.

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

[Aymeric Augustin]

Hello Ahmad,

I believe there's interest for supporting parallel test runs on Oracle, if only 
to make Django's own test suite faster.

I'm not very familiar with spawn vs. fork. As far as I understand, spawn starts 
a new process, so you'll have to redo some initialization in the child 
processes. In a regular application, this would mean calling `django.setup()`. 
In Django's own test suite, it might be different; I don't know. Try it and see 
what breaks, maybe?

Hope this helps :-)

-- 
Aymeric.



> On 23 Mar 2020, at 20:22, Ahmad A. Hussein  wrote:
> 
> Django's parallel test runner works through forking processes, making it 
> incompatible on Windows by default and incompatible in macOS due to a recent 
> update. Windows and macOS both support spawn and have it enabled by default. 
> Databases are cloned for each worker.
> 
> To switch from fork to spawn, state setup will be handled by spawned 
> processes instead of through inheritance via fork. Worker’s connections to 
> databases can still be done through get_test_db_clone_settings which changes 
> the names of databases assigned to a specific worker_id; however, SQLite's 
> cloning method is incompatible with spawn.  
> 
> 
> SQLite’s cloning method relies on it both being in-memory and fork as when we 
> fork the main process, we retain SQLite's in-memory database in the child 
> process. The solution is to get a SQL dump of the database and throw it into 
> the target cloned databases. This is also the established standard in 
> handling MySQL’s cloning process.
> 
> Both Postgresql's and MySQL's cloning methods are independent of fork or 
> spawn and won't require any modification.
> 
> Oracle has not been implemented in the parallel test runner originally even 
> on Linux and I propose to extend support to Oracle as well in my proposal. I 
> want to confirm if there is significant support behind this as a feature or 
> not before I commit to writing a specification, but as a summary it is 
> definitely possible as the work collaborated on by Aymeric Augustin and Shai 
> Berger show that cloning CAN be done through multiple ideas. The reason why 
> it's a headache is that Oracle does not support separate databases under a 
> single user- unlike our other supported databases, so we can't clone 
> databases without introducing another user. Some methods may also need to be 
> rewritten to accommodate for the Oracle backend, but that isn't an issue.
> 
> I've glossed over writing out a schedule or a more detailed abstract as I I'm 
> mainly posting here to see if there is indeed support for the Oracle proposal 
> and to make sure I am not missing any details in regards to adapting the 
> current parallel test runner to work through spawn. Let me know what you 
> think.
> 
> Regards,
> Ahmad
> 
> -- 
> 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/317f67c6-4b23-483f-ada5-9bdbb45d0997%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/08E2379A-F09E-47C3-9464-42206ECCA44A%40polytechnique.org.

Re: Management command that fails when there are created migrations waiting to be applied to the database

[Mariusz Felisiak]

Ticket accepted.

-- 
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/3d1dda6a-1435-498a-9a83-bf1a63ea58f6%40googlegroups.com.

Re: Management command that fails when there are created migrations waiting to be applied to the database

[Mariusz Felisiak]

Now I understand better your use case, you want to exit when you have 
unapplied migrations. Currently you can use `migrate --plan` that shows 
migrations to apply or "No planned migration operations." if such 
migrations don't exist. I agree we can add `migrate --check` option.

Best,
Mariusz

-- 
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/8108fb98-efa1-4bd7-ad76-ea8590189a79%40googlegroups.com.

Re: Management command that fails when there are created migrations waiting to be applied to the database

[Gordon]

Exactly!  I need to know if we will *run* migrations.

On Thursday, March 26, 2020 at 2:59:39 AM UTC-4, Fran Hrženjak wrote:
>
> If I’m understanding correctly, the difference between `makemigrations 
> --check` and your use case is that one checks if we need to *create* any 
> migrations while the other checks (or would check) if we need to *run* any 
> migrations.
>
> Seems reasonable to me. Although I would prefer we just add a `--check` 
> option to the existing `migrate` command to keep it simpler and consistent 
> with the existing option for `makemigrations` command. 
>
>  
>
> On Thu, 26 Mar 2020 at 07:29, Gordon > 
> wrote:
>
>> Good morning.
>>
>> I had created ticket https://code.djangoproject.com/ticket/31402 after 
>> discussing in IRC about a built in way to stop a continuous delivery 
>> pipeline if the deployment would need to run database migrations. (i.e. if 
>> running `python manage.py migration` would do anything or not.
>>
>> In my specific scenario, I would like to run `python manage.py 
>> showmigrations --database=foo --check` and have it fail if there are 
>> unapplied migrations to the 'foo' database (or the default database as the 
>> case may be).  In this case, the automatic deployment would halt to prevent 
>> downtime.
>>
>> The discussion resulted with one must parse the results from `python 
>> manage.py showmigrations`.  I.e. write a script that checks the output of 
>> `showmigrations` for something like '[ ]'.
>>
>> I can certainly do that, but it seems like it would be generally useful 
>> to have this type of command available within Django.  It could be used to 
>> improve the release process for any project that uses some sort of 
>> automatic deployment scenario.
>>
>> The ticket was rejected with the response, use `python manage.py 
>> makemigrations --check`.  However, I believe that this command determines 
>> if the current version of models on disk would result in a new migration 
>> being made.  This is not the same as the functionality I have suggested.  
>> Am I wrong here?
>>
>> Please let me know your thoughts.
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/728bde3f-e68c-4224-9101-5c98a45c1016%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> LP,
> Fran
>
>

-- 
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/b9e04f84-2dd7-4fd7-96a8-35d3a87aea12%40googlegroups.com.

Re: Management command that fails when there are created migrations waiting to be applied to the database

[Fran Hrženjak]

If I’m understanding correctly, the difference between `makemigrations
--check` and your use case is that one checks if we need to *create* any
migrations while the other checks (or would check) if we need to *run* any
migrations.

Seems reasonable to me. Although I would prefer we just add a `--check`
option to the existing `migrate` command to keep it simpler and consistent
with the existing option for `makemigrations` command.



On Thu, 26 Mar 2020 at 07:29, Gordon  wrote:

> Good morning.
>
> I had created ticket https://code.djangoproject.com/ticket/31402 after
> discussing in IRC about a built in way to stop a continuous delivery
> pipeline if the deployment would need to run database migrations. (i.e. if
> running `python manage.py migration` would do anything or not.
>
> In my specific scenario, I would like to run `python manage.py
> showmigrations --database=foo --check` and have it fail if there are
> unapplied migrations to the 'foo' database (or the default database as the
> case may be).  In this case, the automatic deployment would halt to prevent
> downtime.
>
> The discussion resulted with one must parse the results from `python
> manage.py showmigrations`.  I.e. write a script that checks the output of
> `showmigrations` for something like '[ ]'.
>
> I can certainly do that, but it seems like it would be generally useful to
> have this type of command available within Django.  It could be used to
> improve the release process for any project that uses some sort of
> automatic deployment scenario.
>
> The ticket was rejected with the response, use `python manage.py
> makemigrations --check`.  However, I believe that this command determines
> if the current version of models on disk would result in a new migration
> being made.  This is not the same as the functionality I have suggested.
> Am I wrong here?
>
> Please let me know your thoughts.
>
> --
> 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/728bde3f-e68c-4224-9101-5c98a45c1016%40googlegroups.com
> 
> .
>
-- 
LP,
Fran

-- 
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/CAM2o%3DwOT8BGNTZ7Y7oksjZ5nR71XZ2yVUxkWVJhcK1CJnh98Xg%40mail.gmail.com.

Re: GSoC Mentors

[Carlton Gibson]

Thanks Simon, super. 

On Wednesday, 25 March 2020 19:25:27 UTC+1, charettes wrote:
>
> I confirm my willingness to be a mentor for ORM and Migrations related 
> work.
>
> Simon
>
> Le mercredi 25 mars 2020 04:43:49 UTC-4, Carlton Gibson a écrit :
>>
>> Hi all. 
>>
>> We're reaching the end of the application period for GSoC. 
>>
>> In order to know how many students we might accept, we need to know how 
>> many prospective mentors we have. 
>>
>> This falls into two kinds of job: 
>>
>> 1. General project management help: communicating with students to help 
>> them set a schedule and a rhythm, and make sure they're able to make 
>> progress. (The hope is they're self motivated but...) 
>>
>> 2. More technical input. For this I'm thinking particularly about the 
>> migrations framwork (Markus, Simon, Shai, Andrew, ...) but *experienced 
>> hands* with knowledge of the internals: your input would be invaluable 
>> here. 
>>
>> The forum seems to be working well, and it's a good format for this kind 
>> of thing, so I want to aim to focus the discussion there. 
>>
>> I'd like to share the mentoring as a group. We'd need to assign specific 
>> mentors but I don't see why it can't be a group thing. 
>>
>> If you could hang out a bit on the forum (mainly for task 1) and/or offer 
>> technical input, which you might be doing already/anyway (for task 2) then 
>> that would be a super contribution. 
>>
>> Please let me know if you'd be willing to help mentor. 
>>
>> Thanks
>>
>> Kind Regards,
>>
>> Carlton
>>
>>

-- 
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/67b674e0-4163-44b3-91cd-7717b936e1bd%40googlegroups.com.

Management command that fails when there are created migrations waiting to be applied to the database

[Gordon]

Good morning.

I had created ticket https://code.djangoproject.com/ticket/31402 after 
discussing in IRC about a built in way to stop a continuous delivery 
pipeline if the deployment would need to run database migrations. (i.e. if 
running `python manage.py migration` would do anything or not.

In my specific scenario, I would like to run `python manage.py 
showmigrations --database=foo --check` and have it fail if there are 
unapplied migrations to the 'foo' database (or the default database as the 
case may be).  In this case, the automatic deployment would halt to prevent 
downtime.

The discussion resulted with one must parse the results from `python 
manage.py showmigrations`.  I.e. write a script that checks the output of 
`showmigrations` for something like '[ ]'.

I can certainly do that, but it seems like it would be generally useful to 
have this type of command available within Django.  It could be used to 
improve the release process for any project that uses some sort of 
automatic deployment scenario.

The ticket was rejected with the response, use `python manage.py 
makemigrations --check`.  However, I believe that this command determines 
if the current version of models on disk would result in a new migration 
being made.  This is not the same as the functionality I have suggested.  
Am I wrong here?

Please let me know your thoughts.

-- 
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/728bde3f-e68c-4224-9101-5c98a45c1016%40googlegroups.com.