Adding a decorator to include a property in an object's serialization

[Diptesh Choudhuri]

Hello, I hope you are all doing well.

Currently if one wants to have custom properties on their models without 
introducing new columns, they have to use properties:

class Chapter(models.Model):
name = models.CharField()
text = models.TextField()

@property
def word_count(self):
return len(self.text.split())

chapter_one = Chapter.objects.first()

Now, the word count can be accessed using *chapter_one.wordcount*. However, 
when actually serializing this object, the wordcount isn't included:
{
  "name":"Technology",
  "text":"Some long text"
  // "wordcount": 3 <- this is not included
}

This problem can be fixed by updating the resultant serialization yourself.

serialized.update({ "wordcount": chapter_one.wordcount }) 

However, this quickly gets difficult once you have many such properties. 
There are workarounds for this (eg: using the* inspect *module) but they 
are difficult to understand and quickly result in unreadable code.

I propose we add a new decorator which will allow these properties to be 
included in the default object serialization.

*@column_property **# imported from django*
def word_count(self):
return len(self.text.split())

What do you think about this change? I think it'd be good since this won't 
introduce any backwards incompatible change. This change will especially 
benefit those who are creating some kind of API since they won't have to 
write complex code for such a simple use case.

I can open a ticket for this on djangoproject, and start working on this 
soon.

Thanks
Diptesh Choudhuri

-- 
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/b6f33375-cf76-421c-b6d4-3642d0bbb9f1n%40googlegroups.com.

Addressing django and graphql ecosystem

[Diptesh Choudhuri]

Hello everyone, hope you are all doing well!

Despite there being a few tools to integrate GraphQL with Django, the 
community stance towards their union is "it could be much better". This is 
expected, since though these tools exist, they are not made with the best 
developer experience in mind. Their development is very slow if not 
completely unmaintained. Unfortunately this pitiable condition of Django 
and GraphQL turns many developers away from using Django for their GraphQL 
projects.
<https://github.com/IgnisDa/ignisda.me/blob/development/frontend/content/projects/gsoc/2021/django.md#but-why-should-we-focus-on-graphql-then>*Project
 
Idea*
I would like to work on a library that is tightly coupled to django's 
existing and foolproof concepts of Views and Models. Just like django rest 
framework has class based views like DetailView, ListView and the other 
concrete 
view classes 
<https://www.django-rest-framework.org/api-guide/generic-views/#concrete-view-classes>,
 
I would like to implement them in this package.

Next, I plan to tackle authentication using both token and then using JWT. 
I have already implemented a package to achieve token based authentication 
using this <https://github.com/IgnisDa/ariadne-token-auth> package and I 
plan to integrate it with this new project itself. JWT is slightly trickier 
for me and I would have to carefully plan how to go about implementing it.

Pagination is another complex topic which takes some time to develop 
schemas for. Though I have not figured out how to actually implement this 
yet, I will try to develop a basic plan to do it efficiently.

Exception handling is another core feature that needs to be taken special 
care of. As mentioned in this <https://stackoverflow.com/a/59733362> answer, 
GraphQL generally returns a status code of either *200 *OR *500 (*if 
something went really bad). Since it is not possible for clients to check 
if a request actually succeeded on the basis of the returned status code, 
it becomes imperative to return error messages that clearly explain what 
went wrong. I plan to make error handling a breeze by making some helper 
modules.

Though there are existing (and arguably better) packages to do, I have also 
planned on creating serializers 
<https://www.django-rest-framework.org/api-guide/serializers/>, if time 
permits me.

Finally, I have decided to build this package on top on ariadne 
<https://github.com/mirumee/ariadne> and not graphene-django 
<https://github.com/graphql-python/graphene-django>*.* This is because 
there are various design flaws in the latter which make it very unwieldy to 
use, especially while trying to return errors in your response. Though 
ariadne is newer compared to graphene, it is generally, in my experience, 
more stable, easier to use and also support file uploads.

Please let me know what you think about this and whether I should go 
forward with this idea for GSOC.

Regards
Diptesh Choudhuri

PS: *I have also* *started preparing a very much work in progress proposal 
here 
<https://github.com/IgnisDa/ignisda.me/blob/development/frontend/content/projects/gsoc/2021/django.md>,
 
if you are interested.*

-- 
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/37620d9a-7c28-471b-9fa8-d92d8ced6181n%40googlegroups.com.

Re: Add a stable and documented setting to add files to the runserver watcher

[Diptesh Choudhuri]

In that case, I think we should at least start by documenting the `
*autoreload_started*` signal. Can I make a PR for the same? I think the 
best place to document this will be 
at https://github.com/django/django/blob/master/docs/ref/signals.txt
On Monday, February 8, 2021 at 4:37:37 PM UTC+5:30 t...@tomforb.es wrote:

> Hey Diptesh!
> It was always my intention to document and expose the autoreloader signals 
> to third party applications, that way ariadne can configure watches on the 
> graphql files it knows about. I think this is preferable to having users 
> having to configure this directly in their projects. We kept the API as 
> private initially as I wasn’t sure how stable it was going to be, but there 
> haven’t been any major changes required so I think it’s time to open it up 
> and mark it as something packages can build upon, if nobody else disagrees?
>
> Regarding a setting - I’m of two minds about this. It’s a good “escape 
> hatch” for packages that don’t use this signal yet, but it’s also not 
> particularly… great. Not sure.
>
> Tom 
>
> On 8 Feb 2021 at 02:16:45, Diptesh Choudhuri  
> wrote:
>
>> I am working on a graphQL project which uses django and ariadne 
>> <https://ariadnegraphql.org/>. This package supports 
>> <https://ariadnegraphql.org/docs/modularization#defining-schema-in-graphql-files>
>>  
>> loading your graphQL schema from external **.graphql *files. While 
>> developing the schema, I continually change these files and have to restart 
>> my *runserver *every time I do so, since the changes are not watched by 
>> default. This obviously gets quickly tiring since designing a GraphQL 
>> schema takes a lot of iterations.
>>
>> There is a somewhat hacky fix 
>> <https://stackoverflow.com/a/43593959/11667450> to this (here's 
>> <https://github.com/IgnisDa/Gitzer/blob/main/gitzer/director/apps.py#L7> 
>> an implementation that I used in a project), but the problem with it is 
>> that it does not work at all for extensions like *django_extension's 
>> runserver *command. Additionally, it requires you to have to start an 
>> app, since it is defined in the *AppConfig, *something which might be 
>> inconvenient to some people. 
>>
>> I propose we add a *AUTORELOADER_ADD_FILES *variable to the *settings.py 
>> *file which should be a Linux glob (eg: *AUTORELOADER_ADD_FILES = **BASE_DIR 
>> / "**/*.graphql"*).
>>
>> If approved, I would like to make a PR for the same.
>>
>> Regards
>> Diptesh Choudhuri
>>
>> -- 
>>
> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/0164ea90-33a2-4ee5-b6cd-df508b6ab013n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/0164ea90-33a2-4ee5-b6cd-df508b6ab013n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/c71f72b4-c03c-4336-b0d1-9af801c135cdn%40googlegroups.com.

Add a stable and documented setting to add files to the runserver watcher

[Diptesh Choudhuri]

I am working on a graphQL project which uses django and ariadne 
<https://ariadnegraphql.org/>. This package supports 
<https://ariadnegraphql.org/docs/modularization#defining-schema-in-graphql-files>
 
loading your graphQL schema from external **.graphql *files. While 
developing the schema, I continually change these files and have to restart 
my *runserver *every time I do so, since the changes are not watched by 
default. This obviously gets quickly tiring since designing a GraphQL 
schema takes a lot of iterations.

There is a somewhat hacky fix 
<https://stackoverflow.com/a/43593959/11667450> to this (here's 
<https://github.com/IgnisDa/Gitzer/blob/main/gitzer/director/apps.py#L7> an 
implementation that I used in a project), but the problem with it is that 
it does not work at all for extensions like *django_extension's runserver 
*command. 
Additionally, it requires you to have to start an app, since it is defined 
in the *AppConfig, *something which might be inconvenient to some people. 

I propose we add a *AUTORELOADER_ADD_FILES *variable to the *settings.py *file 
which should be a Linux glob (eg: *AUTORELOADER_ADD_FILES = **BASE_DIR / 
"**/*.graphql"*).

If approved, I would like to make a PR for the same.

Regards
Diptesh Choudhuri

-- 
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/0164ea90-33a2-4ee5-b6cd-df508b6ab013n%40googlegroups.com.

Re: collectstatic command should output minified files

[Diptesh Choudhuri]

Correct. Also having to use third party packages (and even other 
languages!) for something so common and so useful feels incorrect somehow. 

Additionally, I also propose that  the HTMl files served by wsgi.py are 
minified. This will be significantly more difficult to achieve since HTML 
pages are served on the fly. But I think the benefits would surely outweigh 
the maintenance costs these features bring.

On Tuesday, December 22, 2020 at 5:03:23 PM UTC+5:30 arvind...@gmail.com 
wrote:

> I didn't mean we should include things in Django. Even a workflow that 
> integrates with Django using manage.py commands will be super useful. 
>
> Right now, I use Parcel + Tailwind (csspostprocessor mostly) + done 
> JavaScript. It's supposed to be simple. 
>
> Even for this, I need to run to terminals (one for Django, one for the 
> frontend) or use something like Honcho with a procfile just so I can 
> develop in peace. Or I should hack gulp to run Django runserver for me. 
>
> This is not documented anywhere officially but is a very very common 
> workflow even for small applications. 
>
> I'm saying we do something to make this an easier process.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* django-d...@googlegroups.com  on 
> behalf of Dmitriy Sintsov 
> *Sent:* Tuesday, December 22, 2020 3:59:15 PM
> *To:* django-d...@googlegroups.com 
> *Subject:* Re: collectstatic command should output minified files 
>  
> There is one trouble: Webpack assumes it's own subtree of assets to 
> process, while Django loads assets from packages (Django apps) directories. 
> I still haven't seen a successful setup of webpack which would respect 
> loading assets from Django packages directories. 
> Another trouble, not everyone wants to carry node.js subsystem with it's 
> huge list of packages in their Python / Django project.
> But there are changes that transpiling would not be required in the future 
> at all, after IE11 would fade to the past:
>
> https://www.freecodecamp.org/news/you-might-not-need-to-transpile-your-javascript-4d5e0a438ca/
>
> On Tue, Dec 22, 2020 at 1:20 PM Adam Johnson  wrote:
>
> django-compressor is also popular: 
> https://pypi.org/project/django-compressor/
>
> IMO we should not include anything in Django since JavaScript is a 
> separate language, and they have much better tools for minification and 
> bundling, and these tools can move faster than and orthogonally to Django. 
> And there are many options: Webpack, Parcel, Gulp, Grunt, Rollup, ..
>
> On Tue, 22 Dec 2020 at 10:06, quest...@gmail.com  
> wrote:
>
> There is CSS / Javascript merge and compress package for Python: 
> https://github.com/miracle2k/webassets
> which supports Django, Flask, Pyramid.
>
> See also:
>
> https://www.slideshare.net/__amol__/pyconit7-dukpy-webassets-free-yourself-from-nodejs-chains
> https://pypi.org/project/dukpy/
> https://gist.github.com/amol-/0fd016bbb0c6c9a0fb6ab5bbedfcb7ad
> https://github.com/rclmenezes/webassets-rollup
>
>
> On Tuesday, December 22, 2020 at 5:03:54 AM UTC+3 arvind...@gmail.com 
> wrote:
>
> I kinda like the idea of being able to run collectstatic and not have to 
> worry about setting up a full on frontend workflow for pretty much just 
> minification. It is a great default to have when this is all you need.
>
> That said, I’d be more interested in seeing something like an official or 
> a django-blessed unofficial default option similar to the sprokects-rails 
> gem for ruby. Allowing for a much more flexible and extensive frontend 
> pipeline without having to rely on an external task runner.
>
> On 22 Dec 2020, at 7:24, Diptesh Choudhuri wrote:
>
> The default files copied to STATIC_ROOT when you run python manage.py 
> collectstatic should have two versions- file.js and file.min.js (similarly 
> for css files). As far as I can see, this happens only for the preinstalled 
> apps (like admin/actions.min.js) but not for user installed apps. 
> Serbing minified static files is important for all production environments 
> for pretty much everyone who uses vanilla django. Though there are packages 
> out there to do this, I feel it is important enough and has enough use 
> cases to be added to the django core.
>
> I can start working on this if it is accepted.
> Let me know what you think!
>
> Best
> Diptesh Choudhuri
>
> -- 
> 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 view this discussion on th

collectstatic command should output minified files

[Diptesh Choudhuri]

The default files copied to STATIC_ROOT when you run python manage.py 
collectstatic should have two versions- file.js and file.min.js (similarly 
for css files). As far as I can see, this happens only for the preinstalled 
apps (like admin/actions.min.js) but not for user installed apps.
Serbing minified static files is important for all production environments 
for pretty much everyone who uses vanilla django. Though there are packages 
out there to do this, I feel it is important enough and has enough use 
cases to be added to the django core.

I can start working on this if it is accepted.
Let me know what you think!

Best
Diptesh Choudhuri

-- 
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/5bcb1522-3486-452e-b061-2cce2bb6d2c9n%40googlegroups.com.

Re: Changing the discovery method for management commands

[Diptesh Choudhuri]

I admit I can't find a lot of use cases for this out there. It is just 
something I think django could benefit from. Please feel free to close this 
issue.

On Sunday, December 20, 2020 at 12:26:45 AM UTC+5:30 Adam Johnson wrote:

> The use case I mentioned applies to lot of packages (and new projects 
>> could benefit from this change too).
>>
>
> Please bring more evidence than just blind assertion.
>
> Also I think it's a net negative, as it complicates the notion of what a 
> management command is. It's against the Zen of Python (
> https://www.python.org/dev/peps/pep-0020/) to provide more than one way 
> of doing things, when only one would suffice.
>
> On Sat, 19 Dec 2020 at 17:58, Diptesh Choudhuri  
> wrote:
>
>> There are no remaining use cases here. The use case I mentioned applies 
>> to lot of packages (and new projects could benefit from this change too).
>>
>> On Saturday, December 19, 2020 at 11:05:55 PM UTC+5:30 Ahmad A. Hussein 
>> wrote:
>>
>>> What are the remaining use cases here? Is the proposed change absolutely 
>>> necessary for these use cases?
>>>
>>>
>>>
>>> On Sat, Dec 19, 2020 at 6:19 PM Diptesh Choudhuri  
>>> wrote:
>>>
>>>> Though its just one file and two directories, the use case is common 
>>>> enough to be used by a lot of packages and I think django should do 
>>>> something to support it officially.
>>>>
>>>> On Saturday, December 19, 2020 at 8:19:28 PM UTC+5:30 
>>>> f.apo...@gmail.com wrote:
>>>>
>>>>> On Saturday, December 19, 2020 at 3:16:51 PM UTC+1 
>>>>> diptesh@gmail.com wrote:
>>>>>
>>>>>> and having to add a bunch of unnecessary files to the source code
>>>>>
>>>>>
>>>>> A bunch? You can literally get away with one file:
>>>>>
>>>>> ➜  testing git:(dc_message_signing) ✗ tree testabc 
>>>>> testabc
>>>>> └── management
>>>>> └── commands
>>>>> └── my_cmd.py
>>>>>
>>>>> This is a complete (!) django app. While I agree that in theory it 
>>>>> would be nice to support some other mechanisms, I do not think it is 
>>>>> worth 
>>>>> the effort given how easy it is to add a command (one file & two 
>>>>> directories)
>>>>>
>>>> -- 
>>>>
>>> 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 view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/django-developers/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/df7a5f44-2f6b-4a42-bcca-767f32b56c43n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/df7a5f44-2f6b-4a42-bcca-767f32b56c43n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> 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/793ce8f4-71e9-408d-b6c9-f83a08fa7c60n%40googlegroups.com.

Re: Changing the discovery method for management commands

[Diptesh Choudhuri]

There are no remaining use cases here. The use case I mentioned applies to 
lot of packages (and new projects could benefit from this change too).

On Saturday, December 19, 2020 at 11:05:55 PM UTC+5:30 Ahmad A. Hussein 
wrote:

> What are the remaining use cases here? Is the proposed change absolutely 
> necessary for these use cases?
>
>
>
> On Sat, Dec 19, 2020 at 6:19 PM Diptesh Choudhuri  
> wrote:
>
>> Though its just one file and two directories, the use case is common 
>> enough to be used by a lot of packages and I think django should do 
>> something to support it officially.
>>
>> On Saturday, December 19, 2020 at 8:19:28 PM UTC+5:30 f.apo...@gmail.com 
>> wrote:
>>
>>> On Saturday, December 19, 2020 at 3:16:51 PM UTC+1 diptesh@gmail.com 
>>> wrote:
>>>
>>>> and having to add a bunch of unnecessary files to the source code
>>>
>>>
>>> A bunch? You can literally get away with one file:
>>>
>>> ➜  testing git:(dc_message_signing) ✗ tree testabc 
>>> testabc
>>> └── management
>>> └── commands
>>> └── my_cmd.py
>>>
>>> This is a complete (!) django app. While I agree that in theory it would 
>>> be nice to support some other mechanisms, I do not think it is worth the 
>>> effort given how easy it is to add a command (one file & two directories)
>>>
>> -- 
>>
> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/df7a5f44-2f6b-4a42-bcca-767f32b56c43n%40googlegroups.com.

Re: Changing the discovery method for management commands

[Diptesh Choudhuri]

Though its just one file and two directories, the use case is common enough 
to be used by a lot of packages and I think django should do something to 
support it officially.

On Saturday, December 19, 2020 at 8:19:28 PM UTC+5:30 f.apo...@gmail.com 
wrote:

> On Saturday, December 19, 2020 at 3:16:51 PM UTC+1 diptesh@gmail.com 
> wrote:
>
>> and having to add a bunch of unnecessary files to the source code
>
>
> A bunch? You can literally get away with one file:
>
> ➜  testing git:(dc_message_signing) ✗ tree testabc 
> testabc
> └── management
> └── commands
> └── my_cmd.py
>
> This is a complete (!) django app. While I agree that in theory it would 
> be nice to support some other mechanisms, I do not think it is worth the 
> effort given how easy it is to add a command (one file & two directories)
>

-- 
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/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com.

Re: Changing the discovery method for management commands

[Diptesh Choudhuri]

I initially created a PR on the *pytest-django *package for this management 
command https://github.com/pytest-dev/pytest-django/issues/897. But after I 
dug into the source code, I realized it is impossible to add a management 
command without creating a django app (and having to add a bunch of 
unnecessary files to the source code). Hence this proposal. Even though 
Tom's solution will work just fine, I feel django should provide an 
alternative (and possibly easier) way to register management commands.

On Saturday, December 19, 2020 at 7:26:45 PM UTC+5:30 f.apo...@gmail.com 
wrote:

> Nothing is stopping pytest-django to also ship a django app for those 
> management commands though
>
> On Saturday, December 19, 2020 at 2:27:57 PM UTC+1 diptesh@gmail.com 
> wrote:
>
>> As you said, most cases. The remaining cases have absolutely no way of 
>> defining management commands. One example is *pytest-django *which 
>> doesn't provide a django app but could benefit with a mangement command 
>> *python 
>> manage.py setup_pytest*.
>>
>> On Saturday, December 19, 2020 at 2:11:32 PM UTC+5:30 Adam Johnson wrote:
>>
>>> Why? I don't see an impetus to avoid creating a Django app. In most use 
>>> cases there are related models or other Django bits to go with a management 
>>> command.
>>>
>>> On Sat, 19 Dec 2020 at 01:48, Diptesh Choudhuri  
>>> wrote:
>>>
>>>> As of now, if you need to create a management command, it is necessary 
>>>> to create a file *app_name/management/commands/my_command.py, *and 
>>>> then add *app_name *to *INSTALLED_APPS *in *settings.py. *This 
>>>> prevents non-django packages from defining their own management commands, 
>>>> because it explicitly requires them to create a django app which just adds 
>>>> a bunch of unnecessary files to their source code.
>>>>
>>>> I propose we overhaul the existing management command discovery system 
>>>> so that it is easier to write management commands. Also I suggest we keep 
>>>> the default discoverer in place so as to maintain backwards compatibility.
>>>>
>>>> All of this will require documentation and I am ready to make a PR for 
>>>> that too. Please tell me if the idea is feasible, and I will get to work 
>>>> on 
>>>> it ASAP.
>>>>
>>>> Best
>>>> Diptesh Choudhuri
>>>>
>>>> -- 
>>>> 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 view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/django-developers/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> 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/79323466-c0b6-4fcf-88a0-b91329bbb40bn%40googlegroups.com.

Re: Changing the discovery method for management commands

[Diptesh Choudhuri]

As you said, most cases. The remaining cases have absolutely no way of 
defining management commands. One example is *pytest-django *which doesn't 
provide a django app but could benefit with a mangement command *python 
manage.py setup_pytest*.

On Saturday, December 19, 2020 at 2:11:32 PM UTC+5:30 Adam Johnson wrote:

> Why? I don't see an impetus to avoid creating a Django app. In most use 
> cases there are related models or other Django bits to go with a management 
> command.
>
> On Sat, 19 Dec 2020 at 01:48, Diptesh Choudhuri  
> wrote:
>
>> As of now, if you need to create a management command, it is necessary to 
>> create a file *app_name/management/commands/my_command.py, *and then add 
>> *app_name 
>> *to *INSTALLED_APPS *in *settings.py. *This prevents non-django packages 
>> from defining their own management commands, because it explicitly requires 
>> them to create a django app which just adds a bunch of unnecessary files to 
>> their source code.
>>
>> I propose we overhaul the existing management command discovery system so 
>> that it is easier to write management commands. Also I suggest we keep the 
>> default discoverer in place so as to maintain backwards compatibility.
>>
>> All of this will require documentation and I am ready to make a PR for 
>> that too. Please tell me if the idea is feasible, and I will get to work on 
>> it ASAP.
>>
>> Best
>> Diptesh Choudhuri
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> 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/8d85fcfa-8d1a-4e03-90e1-a00e07f6b6can%40googlegroups.com.

Changing the discovery method for management commands

[Diptesh Choudhuri]

As of now, if you need to create a management command, it is necessary to 
create a file *app_name/management/commands/my_command.py, *and then add 
*app_name 
*to *INSTALLED_APPS *in *settings.py. *This prevents non-django packages 
from defining their own management commands, because it explicitly requires 
them to create a django app which just adds a bunch of unnecessary files to 
their source code.

I propose we overhaul the existing management command discovery system so 
that it is easier to write management commands. Also I suggest we keep the 
default discoverer in place so as to maintain backwards compatibility.

All of this will require documentation and I am ready to make a PR for that 
too. Please tell me if the idea is feasible, and I will get to work on it 
ASAP.

Best
Diptesh Choudhuri

-- 
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/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

I understand what you mean. Here's a proposal.

Instead of removing the default test runner altogether, I can work on 
adding a *TESTING_BACKEND *variable in *settings.py *with possible values 
being *'django.testing.backends.pytest' *(default) or 
*'django.testing.backends.DefaultRunner'*. This way we need not compromise 
on the features that the default runner provides over pytest. Meanwhile I 
could work on some the issues pytest has by contributing to pytest-dev.

One small question- will a contribution to repositories such as *pytest-dev 
*or *graphene-django *count as contributions to the Django organization in 
GSoC?

Best
Diptesh

PS: I am also conducting a small survey about the same. I will post the 
results here once I get sufficient responses. It would be interesting to 
see how to common public reacts to such a change.

On Tuesday, December 15, 2020 at 10:56:37 PM UTC+5:30 Adam Johnson wrote:

> except the first one- this can be easily solved using a pytest hook
>
>
> It's not easy at all. I tried 4 years ago and failed to find a 
> satisfactory way of running the checks at the appropriate time since the 
> pytest lifecycle (db setup, reporting, etc.) is so different from unittest: 
> https://github.com/pytest-dev/pytest-django/pull/414
>
> Instead they are kind of addons that'd be nice to have.
>>
>
> That's not how we treat stability in Django. These features are necessary, 
> core features for the projects that use them, and we treat them as 
> necessary. Please read the Deprecation Policy: 
> https://docs.djangoproject.com/en/3.1/internals/release-process/#internal-release-deprecation-policy
>  
> .
>
> I appreciate your willingness to improve things and I agree generally 
> pytest is a better test runner experience. But please channel some of your 
> energy into understanding where Django is, where pytest is, how 
> contributions work etc. You will get further than having a long back and 
> forth where you keep asserting that it would be easy to implement.
>
> On Tue, 15 Dec 2020 at 16:58, Diptesh Choudhuri  
> wrote:
>
>> *Adam,*
>> Thanks for your detailed feedback.
>> I will be honest, I couldn't understand any of the points you mentioned 
>> (except the first one- this can be easily solved using a pytest hook). As 
>> you said, these are very rare cases indeed. As a django and pytest user for 
>> some time, I would have encountered atleast one of them when I wrote my 
>> tests. However I never have and hence I would say that these are very rare 
>> cases indeed. 
>> What I am trying to say is that if we include pytest in django core, the 
>> development of these features will only be accelerated. The default runner 
>> advantages you mentioned are not really features that are missing in 
>> pytest. Instead they are kind of addons that'd be nice to have. But the 
>> advantages that I mention of pytest over the default runner are significant 
>> and can tremendously improve developer experience while writing tests.
>>
>> Please don't think I am disregarding your points. I respect and value 
>> your opinions.
>>
>> Best
>> Diptesh
>>
>> On Tuesday, December 15, 2020 at 10:10:06 PM UTC+5:30 Diptesh Choudhuri 
>> wrote:
>>
>>> > A case could be made along the same lines as was made for South.
>>>
>>> Could you please elaborate a bit on this? Maybe provide the relevant 
>>> tickets? I am quite new to this community.
>>>
>>> Thanks!
>>> Best
>>> Diptesh
>>>
>>> On Tuesday, December 15, 2020 at 10:01:03 PM UTC+5:30 
>>> arvind...@gmail.com wrote:
>>>
>>>> A case could be made along the same lines as was made for South. 
>>>>
>>>> Get Outlook for Android <https://aka.ms/ghei36>
>>>>
>>>> --
>>>> *From:* django-d...@googlegroups.com  on 
>>>> behalf of Mariusz Felisiak 
>>>> *Sent:* Tuesday, December 15, 2020 9:58:56 PM
>>>> *To:* Django developers (Contributions to Django itself) <
>>>> django-d...@googlegroups.com>
>>>> *Subject:* Re: Replace the default django test runner to a more robust 
>>>> testing framework (like pytest) 
>>>>  
>>>> Hi,
>>>>
>>>> I agree with René and Adam, pytest and pytest-django already exist, 
>>>> and I don't see why we should copy it to Django or change the default test 
>>>> runner.
>>>>
>>>> Best,
>>>> Mariusz
>>>>
>>>> -- 
>>>> You recei

ARe: Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

*Adam,*
Thanks for your detailed feedback.
I will be honest, I couldn't understand any of the points you mentioned 
(except the first one- this can be easily solved using a pytest hook). As 
you said, these are very rare cases indeed. As a django and pytest user for 
some time, I would have encountered atleast one of them when I wrote my 
tests. However I never have and hence I would say that these are very rare 
cases indeed. 
What I am trying to say is that if we include pytest in django core, the 
development of these features will only be accelerated. The default runner 
advantages you mentioned are not really features that are missing in 
pytest. Instead they are kind of addons that'd be nice to have. But the 
advantages that I mention of pytest over the default runner are significant 
and can tremendously improve developer experience while writing tests.

Please don't think I am disregarding your points. I respect and value your 
opinions.

Best
Diptesh

On Tuesday, December 15, 2020 at 10:10:06 PM UTC+5:30 Diptesh Choudhuri 
wrote:

> > A case could be made along the same lines as was made for South.
>
> Could you please elaborate a bit on this? Maybe provide the relevant 
> tickets? I am quite new to this community.
>
> Thanks!
> Best
> Diptesh
>
> On Tuesday, December 15, 2020 at 10:01:03 PM UTC+5:30 arvind...@gmail.com 
> wrote:
>
>> A case could be made along the same lines as was made for South. 
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>> --
>> *From:* django-d...@googlegroups.com  on 
>> behalf of Mariusz Felisiak 
>> *Sent:* Tuesday, December 15, 2020 9:58:56 PM
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Re: Replace the default django test runner to a more robust 
>> testing framework (like pytest) 
>>  
>> Hi,
>>
>> I agree with René and Adam, pytest and pytest-django already exist, 
>> and I don't see why we should copy it to Django or change the default test 
>> runner.
>>
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/60a4a090-8ff5-477e-9651-db1fbf5c397bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/60a4a090-8ff5-477e-9651-db1fbf5c397bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/39dc54fb-43e9-424f-9ca3-10938741d733n%40googlegroups.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

> A case could be made along the same lines as was made for South.

Could you please elaborate a bit on this? Maybe provide the relevant 
tickets? I am quite new to this community.

Thanks!
Best
Diptesh

On Tuesday, December 15, 2020 at 10:01:03 PM UTC+5:30 arvind...@gmail.com 
wrote:

> A case could be made along the same lines as was made for South. 
>
> Get Outlook for Android 
>
> --
> *From:* django-d...@googlegroups.com  on 
> behalf of Mariusz Felisiak 
> *Sent:* Tuesday, December 15, 2020 9:58:56 PM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Replace the default django test runner to a more robust 
> testing framework (like pytest) 
>  
> Hi,
>
> I agree with René and Adam, pytest and pytest-django already exist, 
> and I don't see why we should copy it to Django or change the default test 
> runner.
>
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/60a4a090-8ff5-477e-9651-db1fbf5c397bn%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/13d8fdb1-74b3-4174-9cc9-c1b046ba124en%40googlegroups.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

> I agree with René and Adam, pytest and pytest-django already exist, and I 
don't see why we should copy it to Django or change the default test runner.
I am not talking about replicating any code-base whatsoever. What I am 
proposing instead is official django support for pytest. Kind of like how 
django supports argon2 for password hashing. We can make this a feature 
using *pip install django[pytest]* and make appropriate changes to the 
*startproject 
*command to create some sane test and configuration files.

Thanks for your input!

Best
Diptesh

On Tuesday, December 15, 2020 at 9:58:57 PM UTC+5:30 Mariusz Felisiak wrote:

> Hi,
>
> I agree with René and Adam, pytest and pytest-django already exist, 
> and I don't see why we should copy it to Django or change the default test 
> runner.
>
> 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/5bf973b5-c843-43e4-a32e-f63ad3c87c9cn%40googlegroups.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

*Ahmad*, thanks for your views! Here's what I think.

> I personally believe it should be in core because a lot of custom 
features we'd like to add to the test runner already exist in pytest's rich 
ecosystem. Just as Tom mentioned, adding timings was a lot harder than 
expected while such a feature already exists in pytest.
Adding to this, since features like this already exist in *pytest*, I don't 
think we should reinvent the wheel and try to implement them from scratch.

I would say the main reason I would like integrate pytest into the django 
core is that since it is much loved among the community, it only makes 
sense to make it official. New users won't have to wrack their heads over 
unittest's basics (it took me a long time to understand *setUp *and *tearDown 
*and even longer to actually use it in a project). *pytest-django *also 
requires you to write much less code for the actual test (compare 
*self.assertEquals(thing1, 
thing2) *with *assert thing1 == thing2*).

I don't intend to write documentation only. I believe this idea has a lot 
of scope, and by integrating the features I have already suggested and the 
ones that will be suggested in the near future, I will end up writing a lot 
of code. So it will fit GSoC's job description. However I thank you for 
mentioning Google Summer of Docs, I will definitely look into it.
On Tuesday, December 15, 2020 at 9:15:47 PM UTC+5:30 Ahmad A. Hussein wrote:

> Hi Diptesh,
>
> This is a great idea! (And one that has had a fair bit of discussion). I 
> don't think anyone holds an opinion against supporting pytest as a testing 
> tool, but I believe the main hurdle is laying a convincing argument why 
> this support should be in Django Core versus remaining in its current 
> third-party state. I personally believe it should be in core because a lot 
> of custom features we'd like to add to the test runner already exist in 
> pytest's rich ecosystem. Just as Tom mentioned, adding timings was a lot 
> harder than expected while such a feature already exists in pytest. 
>
> If we aren't going to add it to core, the question I'd like to raise (and 
> preferably get an answer from experienced pytest-django users/developers) 
> is what changes can we make in core to make it easier for the pytest-django 
> package.
>
> Lastly, if you intend to purely write documentation, I would recommend you 
> apply for next year's Google Season of Docs instead of Google Summer of 
> Code. It would be a better fit for the job description
>
> On Tue, Dec 15, 2020 at 3:52 PM Diptesh Choudhuri  
> wrote:
>
>> Though the django default runner gets the job done, I think its high time 
>> to leverage the power of dedicated frameworks for testing django apps. I 
>> will take up the case of *pytest* here because other frameworks like *nose 
>> *are not widely used.
>>
>> For everyone who has used pytest for testing in django, I think we will 
>> all agree that pytest is much better suited to this task. 
>>
>>1. The passing tests look better.
>>2. Failing tests are much more verbose with where the error actually 
>>occurred.
>>3. Parameterizing the test cases using the default runner requires a 
>>third party library and looks difficult 
>>
>> <http://witkowskibartosz.com/blog/parameterized-django-testcases-at-biking-endorphines.html>
>>  (I 
>>will be honest, I haven't used this package myself at all). 
>>4. Injecting runtime conditions into the tests is quite difficult, if 
>>not impossible, and requires a lot of hacky workarounds.
>>5. I am not sure about this, but the default runner also doesn't 
>>cache results from previously run tests, making retesting unchanged tests 
>>much slower.
>>6. This might sound non-trivial but typing *pytest *is much more 
>>easier than typing *python manage.py test *into the command line.
>>7. IDEs like VSCode can discover tests written for *pytest *but not 
>>the ones written using the default runner. This might not sound a big 
>> deal, 
>>but it is infinitely more easier to run tests using the GUI that these 
>> IDEs 
>>have. They provide real-time feedback and show exactly which tests have 
>>passed and what haven't in the code source itself. Here 
>><https://imgur.com/a/5HKE678> is a picture showing what I mean.
>>8. The directory structure created by *python manage.py startapp 
>>my_app *creates a *tests.py *file. This goes against testing best 
>>practices which say that all tests should be aggregated at one place (as 
>>opposed to inside individual apps).
>>

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

Thank you everyone for your inputs! I don't know how you all are using the 
quote feature, so I will address you all by your names.


   - *Jacob*: Thank you for your support! The ticket you linked to is very 
   helpful. It is upside of 5 years old. *pytest *has evolved a lot over 
   that time, as has django itself. The points raised in the ticket itself are 
   still valid 5 years later and as django is a mature project now, some of 
   its development prowess must go to specifically fixing its weaknesses (I 
   believe the default runner is one). That being said, I also opened another 
   ticket on the same website today about this. Should I close that and bump 
   the one you linked instead?
   - *Tobias*: I understand most of the issues raised are personal 
   preferences. However these preferences have been cultivated by the django 
   community itself, so it would be safe to assume that a lot of django users 
   would have the same preferences. There is no harm in making these 
   preferences official (by including them in the official docs). Once people 
   have a common convention to follow, they will only appreciate it because it 
   makes their lives easier. *pytest *indeed does a lot of magic behind the 
   scenes but I intend to demystify this by writing extensive documentation in 
   the *Advanced Testing *Topics page in the django docs. As for the *subTest 
   *method, I admit to not having done enough research about it and it is 
   completely new to me. However, since its not in common usage, we can safely 
   assume that people don't like using it, don't you agree?
   - *Tom*: Totally agree with everything you said! Especially being able 
   to write more "pythonic" code with *pytest*. Even though our definitions 
   of pythonic might be different, I would boldly suggest that functional 
   testing, which *pytest *prefers, looks much more beautiful and readable 
   than unittest's. class based ones.
   - *René: *Though the option exists, I would humbly argue that its much 
   easier to invoke *pytest *than it is to invoke *python manage.py test*. 
   Most of my focus would be on improving the docs, along with a few changes 
   to code-base itself to make pytest the default and generate a sane 
   *pytest.ini*. On further thought, we can completely remove *pytest.ini *and 
   instead do all configuration from *settings.py *itself. Though 
*pytest-django 
   *exists, I feel that it can be very unforgiving to users who are 
   completely new to testing (I was one not long ago). It doesn't work right 
   out of the box. I sincerely believe this must and should be worked upon. 
   
Thank you everyone for your inputs and I would love to hear some more 
feedback. Also if anyone could teach me how to use the quote function, I 
would highly appreciate it.

Best
Diptesh
On Tuesday, December 15, 2020 at 8:47:24 PM UTC+5:30 re...@fleschenberg.net 
wrote:

> Hi,
>
> On 15.12.20 15:48, Tobias Bengfort wrote:
> > My issue is mostly that pytest uses a lot of magic that is hard to 
> > debug, e.g. the overwritten assert statement or implicit injection of 
> > fixtures. Most pro arguments seem to depend on personal taste.
>
> It should be noted that you can use pytest / pytest-django as a test 
> runner without having to use any other pytest features (it can run 
> unittest-style tests, you don't have to rewrite them). I do think it has 
> some features in the test runner. For example, the -k command line 
> option to quickly select tests, or --last-failed to rerun failed tests.
>
> However, since pytest-django exists and has been working flawlessly for 
> me for several years, I am not sure how much benefit there would be in 
> having this in Django itself.
>
> Regards,
> René
>

-- 
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/64886590-2d95-4c11-ad8d-24d0a746001dn%40googlegroups.com.

Replace the default django test runner to a more robust testing framework (like pytest)

[Diptesh Choudhuri]

Though the django default runner gets the job done, I think its high time 
to leverage the power of dedicated frameworks for testing django apps. I 
will take up the case of *pytest* here because other frameworks like *nose *
are not widely used.

For everyone who has used pytest for testing in django, I think we will all 
agree that pytest is much better suited to this task. 

   1. The passing tests look better.
   2. Failing tests are much more verbose with where the error actually 
   occurred.
   3. Parameterizing the test cases using the default runner requires a 
   third party library and looks difficult 
   

 (I 
   will be honest, I haven't used this package myself at all). 
   4. Injecting runtime conditions into the tests is quite difficult, if 
   not impossible, and requires a lot of hacky workarounds.
   5. I am not sure about this, but the default runner also doesn't cache 
   results from previously run tests, making retesting unchanged tests much 
   slower.
   6. This might sound non-trivial but typing *pytest *is much more easier 
   than typing *python manage.py test *into the command line.
   7. IDEs like VSCode can discover tests written for *pytest *but not the 
   ones written using the default runner. This might not sound a big deal, but 
   it is infinitely more easier to run tests using the GUI that these IDEs 
   have. They provide real-time feedback and show exactly which tests have 
   passed and what haven't in the code source itself. Here 
    is a picture showing what I mean.
   8. The directory structure created by *python manage.py startapp my_app 
*creates 
   a *tests.py *file. This goes against testing best practices which say 
   that all tests should be aggregated at one place (as opposed to inside 
   individual apps).
   9. A single *tests.py *file encourages new, inexperienced developers to 
   write all their tests in a single file. This, yet again, goes against 
   testing best practices which put a lot of emphasis on modularization of 
   tests. Models should be tested in *test_models.py*, views in *test_views.py 
   *etc. 
   10. Though *unittest*'s *setUp *and *tearDown *work fine, I personally 
   find that *pytest*'s fixture system provides a bit more freedom. I might 
   want to put all my test methods in one *class*, but I might not want to 
   run the *setUp *and *tearDown *for every test method. (Let me know if 
   this point is a bit unclear.)

*pytest *and *pytest-django *are quire mature frameworks and don't need a 
lot of changes. We could make it easier to setup tests right out of the 
box. For example, *django-admin startproject my_project *could create a 
*pytest.ini 
*right out of the box in the project root. 

Most of my focus would be on rewriting and adding documentation. Even 
though widely used, *pytest *and *pytest-django *are pretty difficult to 
get started with for a newbie. I intend to fix this by adding a lot of 
examples to the docs (maybe even make a separate repository for this).

*NOTE: I intend to work on this project for GSoC 2021. I am just scouting 
beforehand to see how the community receives it.*

Please let me know what you think of this idea. Any critiques will be 
welcome.

Best,
Diptesh

-- 
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/8c5e0baa-5104-4876-a936-8792b3c8d5b8n%40googlegroups.com.