<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 3:02 AM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 12, 2019 at 4:41 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 12, 2019 at 7:27 AM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 12, 2019 at 3:56 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 12, 2019 at 6:33 AM Julian Taylor <<a href="mailto:jtaylor.debian@googlemail.com" target="_blank">jtaylor.debian@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12.05.19 14:58, Charles R Harris wrote:<br>
> Hi All,<br>
> <br>
> NumPy currently distinguishes between release and development versions<br>
> when running tests. Is there a good reason to continue this practice? I<br>
> ask, because with the last pytest release it would be convenient to<br>
> always include `pytest.ini ` so that we can register markers. The<br>
> presence of `pytest.ini` is how we distinguish betweendevelopment from<br>
> release for testing purposes.<br>
> <br>
<br>
One difference between development and release builds was that in<br>
development releases numpy.testing throws errors on floating point<br>
exceptions while the release version it did not.<br></blockquote></div></div></blockquote><div><br></div><div>I'd prefer to keep this behavior. It's not clear to me if the proposal is to change the behavior or not. <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If that is still the case removing the distinction could require a lot<br>
of changes in upstream test suites that are not regularly run against<br>
development builds.<br>
<br>
The motivation is not quite clear to me, can you please elaborate on<br>
what you want to do.<br></blockquote><div><br></div><div>NumPy pytest testing is NumPy specific and not used downstream like our nose testing framework was, so I don't see why that should affect other projects. What motivates this question is that the new version of pytest released yesterday raises warnings for non-registered markers, `pytest.mark.slow` in particular, and that was causing CI failures. The easiest way to register a mark is using `pytest.ini`, but we currently don't include that in released wheels, only in source releases.</div></div></div></blockquote><div><br></div><div>Adding a pytest.ini file in wheels should be perfectly fine I think,</div><div><br></div></div></div></blockquote><div><br></div><div>It is the absence of pytest.ini that makes it a release, for that is the file that turns warnings into errors.</div></div></div></blockquote><div><br></div><div>Why don't we just always keep pytest.ini, and move the settings for warnings-to-errors to runtests.py or tools/travis_test.sh?</div><div><br></div><div>It's not important how we check, all we need is some mechanism to prevent new warnings creeping in. Same as we set -Wall for building in CI.</div><div><br></div></div></div></blockquote><div><br></div><div>I just checked that current wheels show the warnings when `numpy.test()` is run with latest pytest.  However, moving the `pytest.ini` file into the `numpy` directory is tricky, as we need to tell pytest where to find the installed file (-c option). The simplest short time solution is to ignore the warning, but long term I'm worried that the warning will become an error as pytest is doing this because they want to clean up the their implementation. Ideally there would be a better way to register the marks. Note that we currently deal with the missing `pytest.ini` in wheels by duplicating the warnings filters in `_pytesttester.py` using the pytest command line.</div><div><br></div><div>Adding the `error` filter in the command line worries me, as I'm not sure how the priorities work out, the command line is now appended to the contents of `pytest.ini`.</div><div><br></div><div>Chuck</div></div></div></div></div></div>