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

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 dja

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

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, a

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

o > 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 Ch

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

> 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

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

> 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 cou

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

27;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?

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

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

Changing the discovery method for management commands

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

Re: Changing the discovery method for management commands

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: > >&g

Re: Changing the discovery method for management commands

>> >>> 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 >>

Re: Changing the discovery method for management commands

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:

Re: Changing the discovery method for management commands

nge 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 &

Re: Changing the discovery method for management commands

://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

collectstatic command should output minified files

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-

Re: collectstatic command should output minified files

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 De

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

/ "**/*.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 s

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

sagrees? > > 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 a

Addressing django and graphql ecosystem

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 GSO

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

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)&quo