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 g
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
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,
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-
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
: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
gt;
>>> 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:
>
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
&
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
rg/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 p
> 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
> 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
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
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
ng 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 C
e 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 uns
**/*.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 receiv
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 a
ially 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.
R
19 matches
Mail list logo
