Re: [RFC] Test methods filtering on tests run

[Steve Jalim]

On Tuesday, May 17, 2016 at 11:06:43 AM UTC+1, ludovic coues wrote:
>
> I might be saying something stupid, but rather than filtering test, 
> would it not be better to have a flag to rerun all the test that 
> failed in the previous run ? 
>
>
That's why we extende DiscoverRunner to make 
https://pypi.python.org/pypi/django-juno-testrunner 

It's not the best code, but it works well for us. Maybe something in this 
pattern (ie, a flag to generate and consume a rerun log) might be another 
way?

Steve

 

> So the command would always be the same for testA, testB or even both, 
> and might be more user-friendly if there is a bunch of test failing. 
>
> 2016-05-17 2:32 GMT+02:00 Josh Smeaton : 
>
> > Hi Antonio 
> > 
> > I have the same problem when running tests in Django's test suite. When 
> > there's a failure, I have to copy the test path, paste that, then copy 
> the 
> > failing test. The entire path to the test isn't printed in the failures. 
> I'd 
> > be a big fan of *some* kind of implementation that allows me to filter 
> test 
> > methods. I think I'd prefer some kind of glob syntax though, so I could 
> do: 
> > 
> > ./manage.py test app_package**test_method 
> > 
> > That would allow you to be as targeted as you needed to be. 
> > 
> > Would you mind posting your patch somewhere? Reviewing code along with 
> the 
> > description and seeing potential for changes would be cool. 
> > 
> > Josh 
> > 
> > -- 
> > 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 post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/0f9fc55e-9568-41d1-92f9-79effabd8e4b%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
>
> Cordialement, Coues Ludovic 
> +336 148 743 42 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ed326169-0ec6-481d-bf12-8adb0a0d7d9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for migrations squashing improvements

[Steve Jalim]

Yep, the issue I've been having is squashing more than one app. Once I've
got my head around it, i'll write it up and poss submit a documentation
ticket to help

On 22 May 2015 at 12:05, Piotr Maliński <riklau...@gmail.com> wrote:

> It should allow squash all migrations of one app without any dependencies
> issues. Squashing may have problems if a model was created and later
> removed or when removing RunPython/SQL operations or when reordering
> operations to make the optimizer merge them into less operations (like
> getting bad order for FK, M2M operations).
>
>
> W dniu piątek, 22 maja 2015 10:49:11 UTC+2 użytkownik Steve Jalim napisał:
>>
>> Amen to 3 and 3a - that's been proving one of the fiddliest aspects when
>> there are lots of migrations to squash - trial-end-error checking of how
>> many you can get away with squashing in one go while avoiding dependency
>> issues from other apps
>>
>> On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr Maliński wrote:
>>>
>>> I made some tricky migration squashing in few projects recently. It
>>> works but still could be made better.
>>>
>>> 1. squashed migrations could have explicit flag indicating that it's a
>>> squash-initial migration. More complex squashes or optimizing squash can
>>> lead to problems when it will not fake but try to apply on existing
>>> database. Global --fake isn't a handy solutions for some deployment
>>> solutions. Or just fake every 0001* migration if any other 0001* migration
>>> was applied for given app in the past.
>>> 2. there could be a "resquash" option that would not make a squash of a
>>> squash but just optimize operations if possible for given squash
>>> (application with one migration that is a squash).
>>> 3. there could be a "testmigrations" command/option that would try to
>>> migrate everything on a test database (or just given application with
>>> dependencies) - similar to running some test just to get the migrations
>>> going.
>>> 3a. As a bonus - check if database schema is the same when migrated with
>>> old squash versus new optimized squash.
>>>
>>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/vtf-4II-rEo/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADJx9E9ySVJYvGM5rNKyeyz6ZKjbyOm_KHeJdXOzbXsvgprjwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for migrations squashing improvements

[Steve Jalim]

Amen to 3 and 3a - that's been proving one of the fiddliest aspects when 
there are lots of migrations to squash - trial-end-error checking of how 
many you can get away with squashing in one go while avoiding dependency 
issues from other apps

On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr Maliński wrote:
>
> I made some tricky migration squashing in few projects recently. It works 
> but still could be made better. 
>
> 1. squashed migrations could have explicit flag indicating that it's a 
> squash-initial migration. More complex squashes or optimizing squash can 
> lead to problems when it will not fake but try to apply on existing 
> database. Global --fake isn't a handy solutions for some deployment 
> solutions. Or just fake every 0001* migration if any other 0001* migration 
> was applied for given app in the past.
> 2. there could be a "resquash" option that would not make a squash of a 
> squash but just optimize operations if possible for given squash 
> (application with one migration that is a squash).
> 3. there could be a "testmigrations" command/option that would try to 
> migrate everything on a test database (or just given application with 
> dependencies) - similar to running some test just to get the migrations 
> going.
> 3a. As a bonus - check if database schema is the same when migrated with 
> old squash versus new optimized squash.
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba0832f2-51df-47e4-89e9-5c46d3ad6e29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cleaning up broken pipe errors in runserver

[Steve Jalim]

Naive / over-obvious suggestion: if there's a genuine stalemate, bundling 
the changes into a third-party app that supplants core runserver (similar 
to how django-devserver does it) would avoid the need for individuals to 
monkey-patch while also making it possible to release versions with more 
significant security fixes based on changes to the underlying Python -- 
without tying it to core Django at all. It also puts the decision on the 
developer re whether or not to care about the "fixed" runserver being 
slightly less secure.

In a way, it's punting the issue, but I'm all for anything that "fixes" the 
broken pipe handling: if the fixed runserver existed as a third party app 
today, I'd install it. And better than the issue tanking for another few 
years.

If if then gets enough traction, that opens a case for it core 
re-consideration, potentially. Yup? 

S 

On Monday, November 3, 2014 6:20:35 PM UTC, Tim Graham wrote:
>
> I had a look at the patch.  As I mentioned on the ticket, "I am not really 
> happy with that patch which copies the 
> simple_server.WSGIRequestHandler.handle() method from Python's version in 
> order to override it. The copied version is not in sync with the latest 
> Python and I'd prefer not to be in a position where we'd have to copy 
> changes from there to Django."
>
> Matthew noted, "the change [in WSGIRequestHandler.handle()], made only 
> last month (hence why this PR doesn't currently match it), is the only 
> change to that function since it became part of the standard library in 
> 2006, and is a small potential security issue that doesn't apply to a 
> development server in any case, as that's explicitly listed as being 
> insecure. I don't necessarily think you'd have to keep changes in sync from 
> upstream, as I don't see there would be any changes to this function other 
> than other tiny security issues that don't matter to a development server, 
> but I can see you wouldn't want to be in that potential situation anyway."
>
> I agree with that, however, many people do use runserver in production and 
> several members of the core team feel we should fix security issues with 
> runserver even though the docs say it's not hardened for production use 
> (I'm not one of them). Any more opinions on how to proceed here?
>
> On Wednesday, August 27, 2014 12:52:38 PM UTC-4, Richard Eames wrote:
>>
>> I'm +1 for this, for the same reasons; I have a monkey patch for my 
>> selenium tests which does the same thing as this PR.
>>
>> On Saturday, 2 August 2014 18:20:18 UTC-6, Matthew Somerville wrote:
>>>
>>> Hi,
>>>
>>> I have created a branch at 
>>> https://github.com/dracos/django/compare/pipe-cleaning that builds upon 
>>> a previous patch posted to this list and outputs "Broken pipe" instead of a 
>>> traceback for such an error. As the history below shows, practically 
>>> speaking all reports of broken pipe tracebacks in the log are due to the 
>>> browser cutting off output, and are not helpful to be shown as a full 
>>> traceback. I get them frequently (e.g. hit refresh before your previous 
>>> page has finished loading to sometimes get it), and find them annoying.
>>>
>>> I am posting here because ticket # - 
>>> https://code.djangoproject.com/ticket/ - is marked wontfix. I am 
>>> not "imagei" on that ticket, I just came across the ticket recently whilst 
>>> trying to work out why my Selenium tests on Travis were failing with broken 
>>> pipes when they were fine last week - 
>>> https://github.com/travis-ci/travis-ci/issues/2610 (some change to 
>>> underlying Travis, I assume). Ticket # was opened in May 2007, and 
>>> marked wontfix in September 2007 saying "The best we could is to have a 
>>> more explicit error message." In 2008 someone provided a patch to make 
>>> it a logged error message rather than spew a scary traceback, there was a 
>>> +1 and a "leave as-is", then silence. There was a brief reopening of the 
>>> thread in 2012 by two people who also found the broken pipe tracebacks 
>>> tedious, then nothing further since then. The thread (2008 and 2012) can be 
>>> found at 
>>> https://groups.google.com/forum/#!topic/django-developers/W1Nns9k40EQ
>>>
>>> (The 'python manage.py runserver --help' is a little bit confusing 
>>> because it has a --traceback argument and yet you still get a traceback - 
>>> you have to have read the default options section of the django-admin.py 
>>> documentation to know that only makes a difference to CommandError, not any 
>>> other type of error. My branch also adds "CommandError" to the help output 
>>> of --traceback.)
>>>
>>> The 2008 patch doesn't really work any more, but I think I've made the 
>>> spirit of the same thing on the current Django code. I hope this can be 
>>> considered for inclusion, as I think it tidies up a common issue with 
>>> runserver output that will especially confuse people new to Django. Do let 
>>> me know if I've gone about fixing it in the wrong way, or if I should