From opensource at ronnypfannschmidt.de Mon Oct 1 04:00:53 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Mon, 1 Oct 2018 10:00:53 +0200 Subject: [pytest-dev] Results of the "drop python 3" poll and what i envision to do about it Message-ID: Hi Everyone, the python3 support poll has run its on https://twitter.com/ossronny/status/1043837215175057408 The results have a interesting shape. 37%??? now 09%??? with 3.4 mid 2019 38%??? with the python 2.7 eol 16%??? a year after py 2.7 eol 468 votes in the final result. Its my belief that a increase of the of the sample size wouldn't have changed the outcome of the poll. I observed it rather quickly normalizing into that shape. I consider the 2 peaks important indications of the desires and considerations of people. By my own wishes i'd just go ahead and drop python2 as well, but i don't consider 37% of the community sample to be enough to warrant something with such drastic effects right now. When summing up with the ~9% of the "with 3.4" and also weighting in the larger time-frame and my impression about the rounding twitter uses we get a subjective number of ~49%+-1%. Which i consider a good context for dropping the "general support for python3". So together with support for python3.4 i want pytest to drop support for python2 for the general development. As for maintenance branches for python2 - i proposed the setup in an earlier mail and i would like to make a basic outline for its support. the pytest core developers should actively support, maintain and backport to this branch until python2.7 goes eol, at that point we should transition the python2 maintenance involvement from the core developers from active to passive. Meaning that instead of actively working on porting changes and pushing releases, we instead support the wider community with needs to bring in changes they require and support them with review and releasing. I believe half a year is more than enough to stabilize and sort out the 2.7 maintenance branch, but should i be demonstrated wrong by how this unfolds i'm happy to have this extend this for another year. But for anything after that the bulk of the python2.x maintenance work should be left on the shoulders of companies and individuals that have an actual requirement for that. -- Ronny From opensource at ronnypfannschmidt.de Mon Oct 1 04:38:50 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Mon, 1 Oct 2018 10:38:50 +0200 Subject: [pytest-dev] the requirement for enabling repeated and successive api breakages Message-ID: Hi everyone, yesterday i tried yet again to reshape node structure to allow the integration of function-definition. every time i work with something around those structures it becomes apparent, that its immensely fragile to work within it with backward compat in mind, its so deeply cross-related that every time we try something, something else breaks (just remember the fallout of the introduction of `Package`). as such i want to enable iteration and breaking apis in that area since its simply impossible to sustainable evolve it right now, and im unable and unwilling to throw away a immense amounts of time to keep everything surrounding working exactly as is. the caveat is, that i expect to be at least 10-15 iterations each doing a micro-breakage around a completely messy area of the api. i would like to note that i consider? this crisscross de-tanglement as an absolute necessity to the development of pytest, if we cant detangle massive debts and messes like that, we should just start over from the beginning. -- Ronny From nicoddemus at gmail.com Mon Oct 1 07:13:57 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 1 Oct 2018 08:13:57 -0300 Subject: [pytest-dev] Results of the "drop python 3" poll and what i envision to do about it In-Reply-To: References: Message-ID: Hi Ronny, On Mon, Oct 1, 2018 at 5:01 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi Everyone, > > the python3 support poll has run its on > https://twitter.com/ossronny/status/1043837215175057408 > > The results have a interesting shape. > > 37% now > 09% with 3.4 mid 2019 > 38% with the python 2.7 eol > 16% a year after py 2.7 eol > > 468 votes in the final result. > > > Its my belief that a increase of the of the sample size wouldn't have > changed the outcome of the poll. > I observed it rather quickly normalizing into that shape. > I consider the 2 peaks important indications of the desires and > considerations of people. > > By my own wishes i'd just go ahead and drop python2 as well, but i don't > consider 37% of the community sample to be enough to warrant something > with such drastic effects right now. > When summing up with the ~9% of the "with 3.4" and also weighting in the > larger time-frame and my impression about the rounding twitter uses we > get a subjective number of ~49%+-1%. > Which i consider a good context for dropping the "general support for > python3". > > So together with support for python3.4 i want pytest to drop support for > python2 for the general development. > > As for maintenance branches for python2 - i proposed the setup in an > earlier mail and i would like to make a basic outline for its support. > the pytest core developers should actively support, maintain and > backport to this branch until python2.7 goes eol, > at that point we should transition the python2 maintenance involvement > from the core developers from active to passive. > Sounds good, we should prepare a section in the docs with that outline, and put it in our sidebar. What is not clear to me though is when we will start the python2-maintenance branch. As I understand it, the maintenance branch would go live once we make the first python 3 only release, correct? When do you think we should plan for that to happen? End of 2020 or sooner? > Meaning that instead of actively working on porting changes and pushing > releases, > we instead support the wider community with needs to bring in changes > they require and support them with review and releasing. > I believe half a year is more than enough to stabilize and sort out the > 2.7 maintenance branch, > but should i be demonstrated wrong by how this unfolds i'm happy to have > this extend this for another year. > But for anything after that the bulk of the python2.x maintenance work > should be left on the shoulders of companies and individuals that have > an actual requirement for that. > > -- Ronny > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Mon Oct 1 07:22:06 2018 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 01 Oct 2018 13:22:06 +0200 Subject: [pytest-dev] Results of the "drop python 3" poll and what i envision to do about it In-Reply-To: References: Message-ID: Hi Bruno, Am Montag, den 01.10.2018, 08:13 -0300 schrieb Bruno Oliveira: > Hi Ronny, > > On Mon, Oct 1, 2018 at 5:01 AM RonnyPfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > > Hi Everyone, > > > > > > > > the python3 support poll has run its on > > > > https://twitter.com/ossronny/status/1043837215175057408 > > > > > > > > The results have a interesting shape. > > > > > > > > 37% now > > > > 09% with 3.4 mid 2019 > > > > 38% with the python 2.7 eol > > > > 16% a year after py 2.7 eol > > > > > > > > 468 votes in the final result. > > > > > > > > > > > > Its my belief that a increase of the of the sample size wouldn't > > have > > > > changed the outcome of the poll. > > > > I observed it rather quickly normalizing into that shape. > > > > I consider the 2 peaks important indications of the desires and > > > > considerations of people. > > > > > > > > By my own wishes i'd just go ahead and drop python2 as well, but i > > don't > > > > consider 37% of the community sample to be enough to warrant > > something > > > > with such drastic effects right now. > > > > When summing up with the ~9% of the "with 3.4" and also weighting > > in the > > > > larger time-frame and my impression about the rounding twitter uses > > we > > > > get a subjective number of ~49%+-1%. > > > > Which i consider a good context for dropping the "general support > > for > > > > python3". > > > > > > > > So together with support for python3.4 i want pytest to drop > > support for > > > > python2 for the general development. > > > > > > > > As for maintenance branches for python2 - i proposed the setup in > > an > > > > earlier mail and i would like to make a basic outline for its > > support. > > > > the pytest core developers should actively support, maintain and > > > > backport to this branch until python2.7 goes eol, > > > > at that point we should transition the python2 maintenance > > involvement > > > > from the core developers from active to passive. > > Sounds good, we should prepare a section in the docs with that > outline, and put it in our sidebar. > > What is not clear to me though is when we will start the python2- > maintenance branch. As I understand it, the maintenance branch would > go live once we make the first python 3 only release, correct? When > do you think we should plan for that to happen? End of 2020 or > sooner? In the plan i outlined, the first python 3 only release would be the one that drops 3.4 mid-2019 - at that point in time the maintenance branch would be prepared before release merge time.-- Ronny > > > Meaning that instead of actively working on porting changes and > > pushing > > > > releases, > > > > we instead support the wider community with needs to bring in > > changes > > > > they require and support them with review and releasing. > > > > I believe half a year is more than enough to stabilize and sort out > > the > > > > 2.7 maintenance branch, > > > > but should i be demonstrated wrong by how this unfolds i'm happy to > > have > > > > this extend this for another year. > > > > > > > > But for anything after that the bulk of the python2.x maintenance > > work > > > > should be left on the shoulders of companies and individuals that > > have > > > > an actual requirement for that. > > > > > > > > -- Ronny > > > > > > > > _______________________________________________ > > > > pytest-dev mailing list > > > > pytest-dev at python.org > > > > https://mail.python.org/mailman/listinfo/pytest-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Oct 1 07:29:03 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 1 Oct 2018 08:29:03 -0300 Subject: [pytest-dev] Results of the "drop python 3" poll and what i envision to do about it In-Reply-To: References: Message-ID: On Mon, Oct 1, 2018 at 8:22 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > > In the plan i outlined, the first python 3 only release would be the one > that drops 3.4 mid-2019 - at that point in time the maintenance branch > would be prepared before release merge time. > I see, thanks, forgot that 3.4 EOL is mid 2019. Once we make a release dropping Python 2 and the maintenance branch is up, what will be our policy regarding large changes in the codebase? I mean, once we have access to Python3 only features, I suspect we will want to clean up the codebase quite a bit and make use of those features (keyword-only arguments come to mind). This clean up and use of new features will make porting critical bug-fixes to the maintenance branch a lot more difficult. Should we hold on on large changes Python 3 only changes until Python 2 EOL, or just bite the bullet and see what happens when we try to port critical fixes to the maintenance branch? Also this reminds me: we should document clearly what we consider "critical" that should be ported to the maintenance branch. Cheers,. > -- Ronny > > > > Meaning that instead of actively working on porting changes and pushing > releases, > we instead support the wider community with needs to bring in changes > they require and support them with review and releasing. > I believe half a year is more than enough to stabilize and sort out the > 2.7 maintenance branch, > but should i be demonstrated wrong by how this unfolds i'm happy to have > this extend this for another year. > > But for anything after that the bulk of the python2.x maintenance work > should be left on the shoulders of companies and individuals that have > an actual requirement for that. > > -- Ronny > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Oct 1 08:05:43 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 1 Oct 2018 09:05:43 -0300 Subject: [pytest-dev] the requirement for enabling repeated and successive api breakages In-Reply-To: References: Message-ID: Hi Ronny, >From my POV breaking those internal APIs slowly and with warnings in place is fine, just like it was done with the "marks" API. I suspect that the internal Node creation API sees even less usage than marks, so I think it is fine to break it slowly and with proper warnings in place. One thing we should keep in mind is that we need to provide a clear way for users to update their code, as well as state the motivation to why we are changing things. Cheers On Mon, Oct 1, 2018 at 5:39 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > yesterday i tried yet again to reshape node structure to allow the > integration of function-definition. > every time i work with something around those structures it becomes > apparent, that its immensely fragile to work within it with backward > compat in mind, > its so deeply cross-related that every time we try something, something > else breaks (just remember the fallout of the introduction of `Package`). > > as such i want to enable iteration and breaking apis in that area since > its simply impossible to sustainable evolve it right now, and im unable > and unwilling to throw away a immense amounts of time to keep everything > surrounding working exactly as is. > > the caveat is, that i expect to be at least 10-15 iterations each doing > a micro-breakage around a completely messy area of the api. > i would like to note that i consider this crisscross de-tanglement as > an absolute necessity to the development of pytest, if we cant detangle > massive debts and messes like that, we should just start over from the > beginning. > > -- Ronny > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asottile+pytest at umich.edu Tue Oct 2 16:59:14 2018 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Tue, 2 Oct 2018 13:59:14 -0700 Subject: [pytest-dev] pytest 3.8.2 released! Message-ID: pytest 3.8.2 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Ankit Goel * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Denis Otkidach * Harry Percival * Jeffrey Rackauckas * Jose Carlos Menezes * Ronny Pfannschmidt * Zac-HD * iwanb Happy testing, The pytest Development Team From digitalxero at gmail.com Wed Oct 3 10:36:26 2018 From: digitalxero at gmail.com (Dj Gilcrease) Date: Wed, 3 Oct 2018 07:36:26 -0700 Subject: [pytest-dev] trying to figure out which hook(s) I need to use... Message-ID: I am attempting to build a plugin which given 1. discover-able tests; test_foos.py::test_a, test_users.py::test_b, test_foos.py::test_c, test_foos.py::test_d 2. a "plan" structure like https://pastebin.com/dBwjshRm will produce output like https://pastebin.com/hJ7LGPBY I have the logic in pytest_collection_modifyitems to do so, but the parameterize mark does not work there since pytest_collection_modifyitems is run after pytest_generate_tests and pytest_generate_tests does not seem to have access to enough context to allow me to know which set of parameters I need to use. The main complication is that tests can appear multiple times in a plan/scenario, be parameterized with differing values, and must maintain execution order defined in the plan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Oct 4 09:19:21 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 4 Oct 2018 10:19:21 -0300 Subject: [pytest-dev] Improving pytest internal errors and messages Message-ID: Hi everyone, Often some errors in pytest show a long traceback with the pytest internals, which is noisy and distracting. For example, if a user makes a typo when declaring the scope of a fixture, we get an error like this: ``` ============================================= ERRORS ============================================== _____________________________ ERROR collecting test-scope-mismatch.py _____________________________ src\_pytest\fixtures.py:699: in scope2index return scopes.index(scope) E ValueError: 'modu' is not in list During handling of the above exception, another exception occurred: src\_pytest\runner.py:201: in __init__ self.result = func() src\_pytest\runner.py:265: in call = CallInfo(lambda: list(collector.collect()), "collect") src\_pytest\python.py:475: in collect self.session._fixturemanager.parsefactories(self) src\_pytest\fixtures.py:1321: in parsefactories ids=marker.ids, src\_pytest\fixtures.py:837: in __init__ scope or "function", descr="fixture {}".format(func.__name__), where=baseid src\_pytest\fixtures.py:703: in scope2index descr, "from {} ".format(where) if where else "", scope E ValueError: fixture fix from test-scope-mismatch.py has an unsupported scope value 'modu' !!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!! ===================================== 1 error in 0.16 seconds ===================================== ``` I've opened a WIP PR (https://github.com/pytest-dev/pytest/pull/4077) to deal with this which uses a specific exception type to raise errors in pytest that are "user errors", suppressing the full traceback unless `-vvv` is used. ``` ============================================= ERRORS ============================================== _____________________________ ERROR collecting test-scope-mismatch.py _____________________________ fixture fix from test-scope-mismatch.py has an unsupported scope value 'modu' !!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!! ===================================== 1 error in 0.07 seconds ===================================== ``` This new exception type (I've used UsageError on my PR just for proof of concept) should be part of the public API so plugins can also use it. I'm writing to the ML because it would be beneficial to get feedback from a larger audience about what the *name* of the exception should be. UserError? InternalError? Feedback on the overall approach (exception usage, verbosity handling, etc) is also very welcome! (On the PR there is a list of issues that could use the new mechanism to provide better messages) Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Oct 4 09:44:51 2018 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 4 Oct 2018 15:44:51 +0200 Subject: [pytest-dev] Improving pytest internal errors and messages In-Reply-To: References: Message-ID: <20181004134451.4x3zcwldcgnwt5hc@hooch.localdomain> Hey, On Thu, Oct 04, 2018 at 10:19:21AM -0300, Bruno Oliveira wrote: > This new exception type (I've used UsageError on my PR just for proof of > concept) should be part of the public API so plugins can also use it. > > I'm writing to the ML because it would be beneficial to get feedback from a > larger audience about what the *name* of the exception should be. > > UserError? InternalError? I dislike both, but without having a better idea (sorry :D). Here's why: UsageError is dangerously close to UsageError. It's also not clear from the name why they differ. InternalError sounds like the exceptions prefixed with INTERNALERROR>, (i.e. unhandled exceptions inside pytest), which seems like the exact opposite of what this is. Maybe we should rename UsageError to CliUsageError, or make sure UsageError is usable for this purpose? Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From oliver at bestwalter.de Thu Oct 4 15:20:21 2018 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Thu, 4 Oct 2018 21:20:21 +0200 Subject: [pytest-dev] Improving pytest internal errors and messages In-Reply-To: <20181004134451.4x3zcwldcgnwt5hc@hooch.localdomain> References: <20181004134451.4x3zcwldcgnwt5hc@hooch.localdomain> Message-ID: Hi, I think this is a great idea. About the naming things problem: I don't know if this is overkill, but how about having an exception like e.g. ReportableError or KnownError that errors like using an invalid scope in your example can inherit from (e.g. InvalidScope) can inherit from. All errors inheriting from that ReportableError or KnownError could then be caught at the top level and be reported differently without a noisy traceback (e.g. only printing out the place where it occured and the error type and message). Cheers, Oliver On Thu, 4 Oct 2018 at 15:51 Florian Bruhin wrote: > Hey, > > On Thu, Oct 04, 2018 at 10:19:21AM -0300, Bruno Oliveira wrote: > > This new exception type (I've used UsageError on my PR just for proof of > > concept) should be part of the public API so plugins can also use it. > > > > I'm writing to the ML because it would be beneficial to get feedback > from a > > larger audience about what the *name* of the exception should be. > > > > UserError? InternalError? > > I dislike both, but without having a better idea (sorry :D). Here's why: > > UsageError is dangerously close to UsageError. It's also not clear > from the name why they differ. > > InternalError sounds like the exceptions prefixed with INTERNALERROR>, > (i.e. unhandled exceptions inside pytest), which seems like the exact > opposite of what this is. > > Maybe we should rename UsageError to CliUsageError, or make sure > UsageError is usable for this purpose? > > Florian > > -- > https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > I love long mails! | https://email.is-not-s.ms/ > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Oct 4 15:28:02 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 4 Oct 2018 16:28:02 -0300 Subject: [pytest-dev] Improving pytest internal errors and messages In-Reply-To: References: <20181004134451.4x3zcwldcgnwt5hc@hooch.localdomain> Message-ID: Hi Walter ;) On Thu, Oct 4, 2018 at 4:21 PM Oliver Bestwalter wrote: > About the naming things problem: I don't know if this is overkill, but how > about having an exception like e.g. ReportableError or KnownError that > errors like using an invalid scope in your example can inherit from (e.g. > InvalidScope) can inherit from. All errors inheriting from that > ReportableError or KnownError could then be caught at the top level and be > reported differently without a noisy traceback (e.g. only printing out the > place where it occured and the error type and message). > I think ReportableError is a good name, as I'm having a hard time coming up with a good name that isn't similar to UsageError/UserError. :) Cheers, Bruno. > > > On Thu, 4 Oct 2018 at 15:51 Florian Bruhin wrote: > >> Hey, >> >> On Thu, Oct 04, 2018 at 10:19:21AM -0300, Bruno Oliveira wrote: >> > This new exception type (I've used UsageError on my PR just for proof of >> > concept) should be part of the public API so plugins can also use it. >> > >> > I'm writing to the ML because it would be beneficial to get feedback >> from a >> > larger audience about what the *name* of the exception should be. >> > >> > UserError? InternalError? >> >> I dislike both, but without having a better idea (sorry :D). Here's why: >> >> UsageError is dangerously close to UsageError. It's also not clear >> from the name why they differ. >> >> InternalError sounds like the exceptions prefixed with INTERNALERROR>, >> (i.e. unhandled exceptions inside pytest), which seems like the exact >> opposite of what this is. >> >> Maybe we should rename UsageError to CliUsageError, or make sure >> UsageError is usable for this purpose? >> >> Florian >> >> -- >> https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) >> GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc >> I love long mails! | https://email.is-not-s.ms/ >> > _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver at bestwalter.de Thu Oct 4 17:35:59 2018 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Thu, 4 Oct 2018 23:35:59 +0200 Subject: [pytest-dev] Improving pytest internal errors and messages In-Reply-To: References: <20181004134451.4x3zcwldcgnwt5hc@hooch.localdomain> Message-ID: Glad to help Oliveira ;) On Thu, 4 Oct 2018 at 21:28 Bruno Oliveira wrote: > Hi Walter ;) > > On Thu, Oct 4, 2018 at 4:21 PM Oliver Bestwalter > wrote: > >> About the naming things problem: I don't know if this is overkill, but >> how about having an exception like e.g. ReportableError or KnownError that >> errors like using an invalid scope in your example can inherit from (e.g. >> InvalidScope) can inherit from. All errors inheriting from that >> ReportableError or KnownError could then be caught at the top level and be >> reported differently without a noisy traceback (e.g. only printing out the >> place where it occured and the error type and message). >> > > I think ReportableError is a good name, as I'm having a hard time coming > up with a good name that isn't similar to UsageError/UserError. :) > > Cheers, > Bruno. > > >> >> >> On Thu, 4 Oct 2018 at 15:51 Florian Bruhin wrote: >> >>> Hey, >>> >>> On Thu, Oct 04, 2018 at 10:19:21AM -0300, Bruno Oliveira wrote: >>> > This new exception type (I've used UsageError on my PR just for proof >>> of >>> > concept) should be part of the public API so plugins can also use it. >>> > >>> > I'm writing to the ML because it would be beneficial to get feedback >>> from a >>> > larger audience about what the *name* of the exception should be. >>> > >>> > UserError? InternalError? >>> >>> I dislike both, but without having a better idea (sorry :D). Here's why: >>> >>> UsageError is dangerously close to UsageError. It's also not clear >>> from the name why they differ. >>> >>> InternalError sounds like the exceptions prefixed with INTERNALERROR>, >>> (i.e. unhandled exceptions inside pytest), which seems like the exact >>> opposite of what this is. >>> >>> Maybe we should rename UsageError to CliUsageError, or make sure >>> UsageError is usable for this purpose? >>> >>> Florian >>> >>> -- >>> https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) >>> GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc >>> I love long mails! | https://email.is-not-s.ms/ >>> >> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev at python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.marie at se.com Tue Oct 16 03:19:52 2018 From: sylvain.marie at se.com (Sylvain MARIE) Date: Tue, 16 Oct 2018 07:19:52 +0000 Subject: [pytest-dev] pytest-steps 1.0.0 is out In-Reply-To: References: Message-ID: Dear pytest community pytest-steps 1.0.0 is out! The major change is that it now supports a new ?generator? style where test functions can use the `yield` statement to indicate a distinct test step. It makes it relatively transparent and easy to decompose a test into steps, and possibly change your mind later or reorganize the steps. It only relies on fixtures and parameters so as to be as pytest-friendly as possible. The legacy explicit style is still supported of course. I thought that you might be interested: https://github.com/smarie/python-pytest-steps Kind regards -- Sylvain From opensource at ronnypfannschmidt.de Tue Oct 16 16:50:43 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Tue, 16 Oct 2018 22:50:43 +0200 Subject: [pytest-dev] pytest 3.9.x series Released Message-ID: Hi everyone, due to a release automation bug i introduced, the first officially published? release of the 3.9.x series is 3.9.1 now that its out we finally have a tmp_path fixture among other great improvements. Happy testing! -- Ronny pytest-3.9.1 ======================================= pytest 3.9.1 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: ? pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Bruno Oliveira * Ronny Pfannschmidt * Thomas Hisch Happy testing, The pytest Development Team pytest-3.9.0 ======================================= The pytest team is proud to announce the 3.9.0 release! pytest is a mature Python testing tool with more than a 2000 tests against itself, passing on many different interpreters and platforms. This release contains a number of bugs fixes and improvements, so users are encouraged to take a look at the CHANGELOG: ??? https://docs.pytest.org/en/latest/changelog.html For complete documentation, please visit: ??? https://docs.pytest.org/en/latest/ As usual, you can upgrade from pypi via: ??? pip install -U pytest Thanks to all who contributed to this release, among them: * Andrea Cimatoribus * Ankit Goel * Anthony Sottile * Ben Eyal * Bruno Oliveira * Daniel Hahler * Jeffrey Rackauckas * Jose Carlos Menezes * Kyle Altendorf * Niklas JQ * Palash Chatterjee * Ronny Pfannschmidt * Thomas Hess * Thomas Hisch * Tomer Keren * Victor Maryama Happy testing, The Pytest Development Team From kvas.it at gmail.com Mon Oct 22 19:19:18 2018 From: kvas.it at gmail.com (Vasily Kuznetsov) Date: Tue, 23 Oct 2018 01:19:18 +0200 Subject: [pytest-dev] Deprecation warnings that I didn't cause. Or did I? Message-ID: Hi everyone! Upon running the tests of pytest-console-scripts plugin with pytest 3.9.1 I see 72 deprecation warnings for an API that, as far as I can tell, my plugin doesn't use (see https://github.com/kvas-it/pytest-console-scripts/issues/14 for more details). After replacing the warning in question with an exception in pytest sources I get the full stack trace but it doesn't have any of my code (also documented in the ticket). Could somebody who understands the newly deprecated features take a look at my code (there's not much, the whole extension is just 168 lines of code in one file ) and see if there's something I should be doing differently to avoid the warnings. Pointers to the description of which APIs are planned for removal in 4.0 would also work. Cheers, Vasily -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Oct 22 19:53:03 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 22 Oct 2018 20:53:03 -0300 Subject: [pytest-dev] Deprecation warnings that I didn't cause. Or did I? In-Reply-To: References: Message-ID: Hi Vasily! On Mon, Oct 22, 2018 at 8:19 PM Vasily Kuznetsov wrote: > Hi everyone! > > Could somebody who understands the newly deprecated features take a look > at my code (there's not much, the whole extension is just 168 lines of code > in one file > ) > and see if there's something I should be doing differently to avoid the > warnings. Pointers to the description of which APIs are planned for removal > in 4.0 would also work. > Yeah unfortunately we didn't notice the problem until 3.9 was out. It will be fixed soon by https://github.com/pytest-dev/pytest/pull/4164. Regarding the list of deprecated APIs, please take a look at https://docs.pytest.org/en/latest/deprecations.html. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Oct 22 21:10:46 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 22 Oct 2018 22:10:46 -0300 Subject: [pytest-dev] pytest 3.9.2 Message-ID: Hi folks, pytest 3.9.2 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Ankit Goel * Anthony Sottile * Bruno Oliveira * Ronny Pfannschmidt * Vincent Barbaresi * ykantor Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvas.it at gmail.com Tue Oct 23 05:14:41 2018 From: kvas.it at gmail.com (Vasily Kuznetsov) Date: Tue, 23 Oct 2018 11:14:41 +0200 Subject: [pytest-dev] Deprecation warnings that I didn't cause. Or did I? In-Reply-To: References: Message-ID: Thank you, Bruno! No worries then and I'll watch out for other deprecated APIs. Cheers, Vasily On Tue, Oct 23, 2018 at 1:53 AM Bruno Oliveira wrote: > Hi Vasily! > > On Mon, Oct 22, 2018 at 8:19 PM Vasily Kuznetsov > wrote: > >> Hi everyone! >> >> Could somebody who understands the newly deprecated features take a look >> at my code (there's not much, the whole extension is just 168 lines of code >> in one file >> ) >> and see if there's something I should be doing differently to avoid the >> warnings. Pointers to the description of which APIs are planned for removal >> in 4.0 would also work. >> > > Yeah unfortunately we didn't notice the problem until 3.9 was out. It will > be fixed soon by https://github.com/pytest-dev/pytest/pull/4164. > > Regarding the list of deprecated APIs, please take a look at > https://docs.pytest.org/en/latest/deprecations.html. > > Cheers, > Bruno. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From variedthoughts at gmail.com Tue Oct 23 15:20:38 2018 From: variedthoughts at gmail.com (Brian Okken) Date: Tue, 23 Oct 2018 12:20:38 -0700 Subject: [pytest-dev] fixture scope wrapping parametrizations Message-ID: Hi, Is there a way to get a fixture scope such that it runs setup before the first parametrization of a test and teardown after the last parametrization? Best I've come up with so far is putting each test into a class and using a class scope fixture. But it seems like a hack. Thanks, Brian Okken -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Tue Oct 23 19:13:16 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 23 Oct 2018 20:13:16 -0300 Subject: [pytest-dev] Enable "WIP" application in pytest Message-ID: Hi everyone, We often have PRs that are a WIP and should not be merged. I was thinking of enabling the WIP application (https://github.com/apps/wip) for pytest-dev/pytest and see if it is useful. Any thoughts? If nobody raises concerns I intend to enable this tomorrow. :) Cheers, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Wed Oct 24 06:12:43 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Wed, 24 Oct 2018 12:12:43 +0200 Subject: [pytest-dev] Enable "WIP" application in pytest In-Reply-To: References: Message-ID: <5961000b-543b-62f2-b4e4-1e219812c90e@ronnypfannschmidt.de> +1 On 24.10.2018 01:13, Bruno Oliveira wrote: > Hi everyone, > > We often have PRs that are a WIP and should not be merged. I was > thinking of enabling the WIP application (https://github.com/apps/wip) > for pytest-dev/pytest and see if it is useful. > > Any thoughts? If nobody raises concerns I intend to enable this > tomorrow. :) > > Cheers, > Bruno > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sat Oct 27 12:37:30 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 27 Oct 2018 13:37:30 -0300 Subject: [pytest-dev] pytest 3.9.3 Message-ID: Hi everyone, pytest 3.9.3 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Andreas Profous * Ankit Goel * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Jon Dufresne * Ronny Pfannschmidt Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: