From tibor.arpas at infinit.sk Sat Nov 2 16:52:44 2019 From: tibor.arpas at infinit.sk (Tibor Arpas) Date: Sat, 2 Nov 2019 21:52:44 +0100 Subject: [pytest-dev] all nodeids from a collected python file Message-ID: Hi, For pytest-testmon plugin I need to extract all node ids which exist in a python file (after parametrization). Initially, I thought pytest_collection_modifyitems used as a hookwrapper would have all the node_ids in all the files (which would be ideal for me). It turns out if you call pytest test_a.py::test_1 , pytest_collection_modifyitems only gets test_a.py::test_1 (but no other nodes which might be in test_a.py). pytest_pycollect_makemodule sounds like the pretty low-level hook which should get all I need. However, it gets a hierarchy, which I have to manually flatten. My gen_nodeids bellow looks like a code that definitely lives somewhere in pytest. What is the optimal and most forward-compatible way to get the list, please? Below is what I came up with so far (and it seems to work). I would be glad to get any comments or pointers. Best, Tibor twitter: tibor_a import pytest pytest_plugins = "pytester" def test_pytest_assumption(testdir): testdir.makepyfile(test_a=""" class Test1(): def test_1(self): pass """) class Plugin: @pytest.hookimpl(hookwrapper=True) def pytest_pycollect_makemodule(self, path, parent): def gen_nodeids(nodes): for node in nodes: if isinstance(node, pytest.Function): yield node.nodeid else: yield from gen_nodeids(node.collect()) make_module_result = yield nodeids = list(gen_nodeids(make_module_result.get_result().collect())) assert nodeids == ['test_a.py::Test1::test_1'] result = testdir.runpytest_inprocess("--testmon-dev", plugins=[Plugin()]) result.assert_outcomes(1, 0, 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibor.arpas at infinit.sk Sat Nov 2 19:35:25 2019 From: tibor.arpas at infinit.sk (Tibor Arpas) Date: Sun, 3 Nov 2019 00:35:25 +0100 Subject: [pytest-dev] all nodeids from a collected python file In-Reply-To: References: Message-ID: So my method doesn't work when Packages are involved. package.collect() returns the necessary nodes only once (it thinks the second execution encountered duplicates, so it returns empty tuple). So my gen_nodeids breaks normal collection. The bug or feature is demonstrated below. Is there a better way, please? If I invoke runpytest with "--keepduplicates" the test passes. Maybe I could use package._collectfile(..., handle_dupes=False) but that is non-API territory so I didn't investigate further yet. Tibor This fails with /Users/tibor/tmonworkspace/testmon.io/test/test_collect.py:33: in pytest_collect_file assert nodeids == nodeids2 E AssertionError: assert ['test_a.py::Test1::test_1', 'test_a.py::Test1::test_2'] == [] import pytest pytest_plugins = "pytester" def test_pytest_assumption(testdir): testdir.makepyfile(__init__="") testdir.makepyfile(test_a=""" class Test1(): def test_1(self): pass def test_2(self): pass """) class Plugin: @pytest.hookimpl(hookwrapper=True) def pytest_collect_file(self, path, parent): def gen_nodeids(nodes): for node in nodes: if isinstance(node, pytest.Item): yield node.nodeid else: yield from gen_nodeids(node.collect()) collect_file_result = yield nodeids = list(gen_nodeids(collect_file_result.get_result())) nodeids2 = list(gen_nodeids(collect_file_result.get_result())) assert len(nodeids) == 2 assert nodeids == nodeids2 result = testdir.runpytest_inprocess("-v", "test_a.py::Test1::test_1", plugins=[Plugin()]) result.assert_outcomes(1, 0, 0) On Sat, Nov 2, 2019 at 9:52 PM Tibor Arpas wrote: > Hi, > > For pytest-testmon plugin I need to extract all node ids which exist in a > python file (after parametrization). Initially, I thought > pytest_collection_modifyitems used as a hookwrapper would have all the > node_ids in all the files (which would be ideal for me). It turns out if > you call pytest test_a.py::test_1 , pytest_collection_modifyitems only gets > test_a.py::test_1 (but no other nodes which might be in test_a.py). > pytest_pycollect_makemodule sounds like the pretty low-level hook which > should get all I need. However, it gets a hierarchy, which I have to > manually flatten. My gen_nodeids bellow looks like a code that definitely > lives somewhere in pytest. What is the optimal and most forward-compatible > way to get the list, please? Below is what I came up with so far (and it > seems to work). > > I would be glad to get any comments or pointers. > > Best, > Tibor > twitter: tibor_a > > import pytest > > pytest_plugins = "pytester" > > > def test_pytest_assumption(testdir): > testdir.makepyfile(test_a=""" > class Test1(): > def test_1(self): > pass > """) > > class Plugin: > @pytest.hookimpl(hookwrapper=True) > def pytest_pycollect_makemodule(self, path, parent): > def gen_nodeids(nodes): > for node in nodes: > if isinstance(node, pytest.Function): > yield node.nodeid > else: > yield from gen_nodeids(node.collect()) > > make_module_result = yield > nodeids = list(gen_nodeids(make_module_result.get_result().collect())) > assert nodeids == ['test_a.py::Test1::test_1'] > > result = testdir.runpytest_inprocess("--testmon-dev", plugins=[Plugin()]) > result.assert_outcomes(1, 0, 0) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibor.arpas at infinit.sk Sun Nov 3 02:24:01 2019 From: tibor.arpas at infinit.sk (Tibor Arpas) Date: Sun, 3 Nov 2019 08:24:01 +0100 Subject: [pytest-dev] all nodeids from a collected python file In-Reply-To: References: Message-ID: So my last iteration is here. It felt unintuitive to use pycollect_makeitem, but seems to be the solution, after all. If you see any flaws I would be grateful to hear about them. Tibor @pytest.hookimpl(tryfirst=True, hookwrapper=True) def pytest_pycollect_makeitem(self, collector, name, obj): makeitem_result = yield items = makeitem_result.get_result() if items: try: self.raw_nodeids.extend([item.nodeid for item in items if isinstance(item, pytest.Item)]) except TypeError: # 'Class' object is not iterable pass The whole test script: import pytest pytest_plugins = "pytester" def test_pytest_assumption(testdir): testdir.makepyfile(__init__="") testdir.makepyfile(test_a=""" import pytest class Test1(): @pytest.mark.parametrize('a', [1, 2]) def test_1(self, a): pass def test_2(self): pass """) class Plugin: def __init__(self): self.raw_nodeids = [] @pytest.hookimpl(tryfirst=True, hookwrapper=True) def pytest_pycollect_makeitem(self, collector, name, obj): makeitem_result = yield items = makeitem_result.get_result() if items: try: self.raw_nodeids.extend([item.nodeid for item in items if isinstance(item, pytest.Item)]) except TypeError: # 'Class' object is not iterable pass plugin = Plugin() result = testdir.runpytest_inprocess("test_a.py::Test1::test_2", plugins=[plugin]) assert plugin.raw_nodeids == ['test_a.py::Test1::test_1[1]', 'test_a.py::Test1::test_1[2]', 'test_a.py::Test1::test_2'] result.assert_outcomes(1, 0, 0) On Sun, Nov 3, 2019 at 12:35 AM Tibor Arpas wrote: > So my method doesn't work when Packages are involved. package.collect() > returns the necessary nodes only once (it thinks the second execution > encountered duplicates, so it returns empty tuple). So my gen_nodeids > breaks normal collection. The bug or feature is demonstrated below. Is > there a better way, please? If I invoke runpytest with "--keepduplicates" > the test passes. Maybe I could use package._collectfile(..., > handle_dupes=False) but that is non-API territory so I didn't investigate > further yet. > > Tibor > > This fails with > /Users/tibor/tmonworkspace/testmon.io/test/test_collect.py:33: in > pytest_collect_file > assert nodeids == nodeids2 > E AssertionError: assert ['test_a.py::Test1::test_1', > 'test_a.py::Test1::test_2'] == [] > > import pytest > > pytest_plugins = "pytester" > > > def test_pytest_assumption(testdir): > testdir.makepyfile(__init__="") > > testdir.makepyfile(test_a=""" > class Test1(): > def test_1(self): > pass > def test_2(self): > pass > """) > > class Plugin: > > @pytest.hookimpl(hookwrapper=True) > def pytest_collect_file(self, path, parent): > def gen_nodeids(nodes): > for node in nodes: > if isinstance(node, pytest.Item): > yield node.nodeid > else: > yield from gen_nodeids(node.collect()) > > > collect_file_result = yield > nodeids = list(gen_nodeids(collect_file_result.get_result())) > nodeids2 = list(gen_nodeids(collect_file_result.get_result())) > assert len(nodeids) == 2 > assert nodeids == nodeids2 > > result = testdir.runpytest_inprocess("-v", "test_a.py::Test1::test_1", plugins=[Plugin()]) > result.assert_outcomes(1, 0, 0) > > > > On Sat, Nov 2, 2019 at 9:52 PM Tibor Arpas wrote: > >> Hi, >> >> For pytest-testmon plugin I need to extract all node ids which exist in a >> python file (after parametrization). Initially, I thought >> pytest_collection_modifyitems used as a hookwrapper would have all the >> node_ids in all the files (which would be ideal for me). It turns out if >> you call pytest test_a.py::test_1 , pytest_collection_modifyitems only gets >> test_a.py::test_1 (but no other nodes which might be in test_a.py). >> pytest_pycollect_makemodule sounds like the pretty low-level hook which >> should get all I need. However, it gets a hierarchy, which I have to >> manually flatten. My gen_nodeids bellow looks like a code that definitely >> lives somewhere in pytest. What is the optimal and most forward-compatible >> way to get the list, please? Below is what I came up with so far (and it >> seems to work). >> >> I would be glad to get any comments or pointers. >> >> Best, >> Tibor >> twitter: tibor_a >> >> import pytest >> >> pytest_plugins = "pytester" >> >> >> def test_pytest_assumption(testdir): >> testdir.makepyfile(test_a=""" >> class Test1(): >> def test_1(self): >> pass >> """) >> >> class Plugin: >> @pytest.hookimpl(hookwrapper=True) >> def pytest_pycollect_makemodule(self, path, parent): >> def gen_nodeids(nodes): >> for node in nodes: >> if isinstance(node, pytest.Function): >> yield node.nodeid >> else: >> yield from gen_nodeids(node.collect()) >> >> make_module_result = yield >> nodeids = list(gen_nodeids(make_module_result.get_result().collect())) >> assert nodeids == ['test_a.py::Test1::test_1'] >> >> result = testdir.runpytest_inprocess("--testmon-dev", plugins=[Plugin()]) >> result.assert_outcomes(1, 0, 0) >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibor.arpas at infinit.sk Tue Nov 5 16:18:35 2019 From: tibor.arpas at infinit.sk (Tibor Arpas) Date: Tue, 5 Nov 2019 22:18:35 +0100 Subject: [pytest-dev] pytest-testmon 1.0.0 alpha In-Reply-To: References: Message-ID: Hi, pytest-testmon 1.0.0 alpha was just published to PYPI and I would like to ask the community for help. pytest-testmon is a pytest plugin which selects end executes only tests affected by recent changes. In a quest for improved speed and reliability, there is a new base algorithm and new data model. There are a lot of new checks to avoid corrupting testmon database (e.g. when you try to execute coverage, debugger or xdist with testmon). install through pip install --pre pytest-testmon and use through pytest --testmon Please give testmon a try and let us know if it works or not on your project. Any remaining bugs will be squashed quickly. Best, Tibor https://testmon.org - test only what changed -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Nov 14 16:20:58 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 14 Nov 2019 18:20:58 -0300 Subject: [pytest-dev] pytest 5.2.3 Message-ID: pytest 5.2.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: * Anthony Sottile * Brett Cannon * Bruno Oliveira * Daniel Hahler * Daniil Galiev * David Szotten * Florian Bruhin * Patrick Harmon * Ran Benita * Zac Hatfield-Dodds * Zak Hassan Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From asottile+pytest at umich.edu Fri Nov 15 18:01:07 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Fri, 15 Nov 2019 15:01:07 -0800 Subject: [pytest-dev] pytest 5.2.4 released Message-ID: pytest 5.2.4 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: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Hugo * Michael Shields Happy testing, The pytest Development Team From iomumtaz at gmail.com Sat Nov 16 21:48:33 2019 From: iomumtaz at gmail.com (Imran M) Date: Sat, 16 Nov 2019 18:48:33 -0800 Subject: [pytest-dev] Plugin Submission "pytest-stress " Message-ID: Hi everyone, I would like to submit this plugin: https://github.com/ImXron/pytest-stress Please let me know if you have any questions / concerns. Thanks! -Imran -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Mon Nov 18 04:57:27 2019 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 18 Nov 2019 10:57:27 +0100 Subject: [pytest-dev] Plugin Submission "pytest-stress " In-Reply-To: References: Message-ID: <20191118095727.4rpla6lezf7yieor@hooch.localdomain> Hey Imran, On Sat, Nov 16, 2019 at 06:48:33PM -0800, Imran M wrote: > I would like to submit this plugin: > > https://github.com/ImXron/pytest-stress > > Please let me know if you have any questions / concerns. Looks interesting! I'm not entirely sure what you mean with "submit" though - would you like the plugin to live under the pytest-dev organization rather than your own GitHub account, as per https://docs.pytest.org/en/latest/contributing.html#submitplugin ? If so, +1 from me! 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 nicoddemus at gmail.com Mon Nov 18 07:51:23 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 18 Nov 2019 09:51:23 -0300 Subject: [pytest-dev] Plugin Submission "pytest-stress " In-Reply-To: <20191118095727.4rpla6lezf7yieor@hooch.localdomain> References: <20191118095727.4rpla6lezf7yieor@hooch.localdomain> Message-ID: On Mon, Nov 18, 2019 at 7:04 AM Florian Bruhin wrote: > If so, +1 from me! > +1 from me too. Feel free to transfer the repository to me or Florian so we can complete the transferring process. Cheers, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: From iomumtaz at gmail.com Mon Nov 18 21:02:59 2019 From: iomumtaz at gmail.com (Imran M) Date: Mon, 18 Nov 2019 18:02:59 -0800 Subject: [pytest-dev] Plugin Submission "pytest-stress " In-Reply-To: References: <20191118095727.4rpla6lezf7yieor@hooch.localdomain> Message-ID: @Florian, Yup! Sorry, should have clarified. @Bruno, transferred! Thanks guys! ? On Mon, Nov 18, 2019 at 4:51 AM Bruno Oliveira wrote: > > > On Mon, Nov 18, 2019 at 7:04 AM Florian Bruhin > wrote: > >> If so, +1 from me! >> > > +1 from me too. Feel free to transfer the repository to me or Florian so > we can complete the transferring process. > > Cheers, > Bruno > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Nov 18 21:05:05 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 18 Nov 2019 23:05:05 -0300 Subject: [pytest-dev] Plugin Submission "pytest-stress " In-Reply-To: References: <20191118095727.4rpla6lezf7yieor@hooch.localdomain> Message-ID: Imran, I've completed the move to pytest-dev and configured the teams. Please let me know if anything is not working correctly for you. Cheers, On Mon, Nov 18, 2019 at 11:03 PM Imran M wrote: > @Florian, Yup! Sorry, should have clarified. > > @Bruno, transferred! > > Thanks guys! ? > > On Mon, Nov 18, 2019 at 4:51 AM Bruno Oliveira > wrote: > >> >> >> On Mon, Nov 18, 2019 at 7:04 AM Florian Bruhin >> wrote: >> >>> If so, +1 from me! >>> >> >> +1 from me too. Feel free to transfer the repository to me or Florian so >> we can complete the transferring process. >> >> Cheers, >> Bruno >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Tue Nov 19 17:19:17 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 19 Nov 2019 19:19:17 -0300 Subject: [pytest-dev] pytest 5.3.0 Message-ID: The pytest team is proud to announce the 5.3.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: * AnjoMan * Anthony Sottile * Anton Lodder * Bruno Oliveira * Daniel Hahler * Gregory Lee * Josh Karpel * JoshKarpel * Joshua Storck * Kale Kundert * MarcoGorelli * Michael Krebs * NNRepos * Ran Benita * TH3CHARLie * Tibor Arpas * Zac Hatfield-Dodds * ?? Happy testing, The Pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From philosophe at gmail.com Thu Nov 21 14:56:12 2019 From: philosophe at gmail.com (Derek Sisson) Date: Thu, 21 Nov 2019 11:56:12 -0800 Subject: [pytest-dev] collecting tests from a testsuite file Message-ID: A quick sanity-check question: is there a plugin or otherwise obvious way to specify tests to run by pulling the names of the tests in from a static file? It pains me to ask this, because it is so retrograde with respect to the power of dynamic collection. Basically, I need to list out the names of test methods in static file, and then collect those tests. For example: testuite.py tests = ['test_1', 'test_2', 'test_3[param_foo]', etc] thanks, --derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.a.sobolev at gmail.com Thu Nov 21 17:03:41 2019 From: n.a.sobolev at gmail.com (=?UTF-8?B?0J3QuNC60LjRgtCwINCh0L7QsdC+0LvQtdCy?=) Date: Fri, 22 Nov 2019 01:03:41 +0300 Subject: [pytest-dev] django-test-migrations and a pytest plugin Message-ID: Hello everyone, I wrote a simple tool to test Django migrations: both schema and data ones. https://github.com/wemake-services/django-test-migrations It also includes a pytest plugin, so you might be interested in it. Here's the announcing post: https://sobolevn.me/2019/10/testing-django-migrations Any feedback is welcome! Best regards, Nikita Sobolev -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Sun Nov 24 17:29:05 2019 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Sun, 24 Nov 2019 23:29:05 +0100 Subject: [pytest-dev] Requesting a change of our deprecation policy and the potentially removal of the features branch Message-ID: <28506244-632f-040b-fc2f-aa49d7920aab@ronnypfannschmidt.de> Hi everyone, in the last few months i have tried to find a way to work with/around our deprecation policy while detangleing Nodes (and something similar will be required for fixtures as well). This process has been rather frustrating and time-eating so far, additionally the changes (like for example node-from-parent) do not nearly deliver as much value as i hoped it would. For me personally i arrived at the conclusion, that if the current deprecation policy stays, its no longer reasonable for me to spend time on trying to restructure the entangled? internals of pytest. In addition, even when attempting to iterate this in small breaking increments, its abysmally ineffective from a feedback loop standpoint to have the feature branch gate such changes for longer time-frames. As such i want to request that we enable pushing for "reasonably sized" breaking changes way more often. (where reasonably sized means touches exposed internals/structure in such a way that it wont affect normal? users, but might affect plugins that are deeply involved) (examples of this are dropping support for the config/session parameters for node constructors, changing the behavior of the node-id creation, changing the config object initialization lifecycle/state? management). And additionally i want to request dropping the feature branch mechanism in order to get a much tighter feedback loop on the changes going in. -- Ronny From nicoddemus at gmail.com Mon Nov 25 10:02:08 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Nov 2019 12:02:08 -0300 Subject: [pytest-dev] Requesting a change of our deprecation policy and the potentially removal of the features branch In-Reply-To: <28506244-632f-040b-fc2f-aa49d7920aab@ronnypfannschmidt.de> References: <28506244-632f-040b-fc2f-aa49d7920aab@ronnypfannschmidt.de> Message-ID: Hi Ronny, Thanks for writing up. Personally I'm tired of arguing for having the "features" branch around, which most core devs think it is not necessary, so I'm OK with us dropping it and just having a `master` branch, with each release being potentially a bugfix or a feature release. Cheers, Bruno On Sun, Nov 24, 2019 at 7:36 PM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > in the last few months i have tried to find a way to work with/around > our deprecation policy while detangleing Nodes (and something similar > will be required for fixtures as well). > > This process has been rather frustrating and time-eating so far, > additionally the changes (like for example node-from-parent) do not > nearly deliver as much value as i hoped it would. > > For me personally i arrived at the conclusion, that if the current > deprecation policy stays, > its no longer reasonable for me to spend time on trying to restructure > the entangled internals of pytest. > > In addition, even when attempting to iterate this in small breaking > increments, > its abysmally ineffective from a feedback loop standpoint to have the > feature branch gate such changes for longer time-frames. > > As such i want to request that we enable pushing for "reasonably sized" > breaking changes way more often. > > (where reasonably sized means touches exposed internals/structure in > such a way that it wont affect normal users, but might affect plugins > that are deeply involved) > > (examples of this are dropping support for the config/session parameters > for node constructors, changing the behavior of the node-id creation, > changing the config object initialization lifecycle/state management). > > > And additionally i want to request dropping the feature branch mechanism > in order to get a much tighter feedback loop on the changes going in. > > > -- 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 Nov 25 11:20:55 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Nov 2019 13:20:55 -0300 Subject: [pytest-dev] Requesting a change of our deprecation policy and the potentially removal of the features branch In-Reply-To: References: <28506244-632f-040b-fc2f-aa49d7920aab@ronnypfannschmidt.de> Message-ID: Hi everyone, I'm also fine to discuss changes to our deprecation policy as Ronny is suggesting. Cheers, Bruon On Mon, Nov 25, 2019 at 12:02 PM Bruno Oliveira wrote: > Hi Ronny, > > Thanks for writing up. > > Personally I'm tired of arguing for having the "features" branch around, > which most core devs think it is not necessary, so I'm OK with us dropping > it and just having a `master` branch, with each release being potentially a > bugfix or a feature release. > > Cheers, > Bruno > > On Sun, Nov 24, 2019 at 7:36 PM RonnyPfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > >> Hi everyone, >> >> in the last few months i have tried to find a way to work with/around >> our deprecation policy while detangleing Nodes (and something similar >> will be required for fixtures as well). >> >> This process has been rather frustrating and time-eating so far, >> additionally the changes (like for example node-from-parent) do not >> nearly deliver as much value as i hoped it would. >> >> For me personally i arrived at the conclusion, that if the current >> deprecation policy stays, >> its no longer reasonable for me to spend time on trying to restructure >> the entangled internals of pytest. >> >> In addition, even when attempting to iterate this in small breaking >> increments, >> its abysmally ineffective from a feedback loop standpoint to have the >> feature branch gate such changes for longer time-frames. >> >> As such i want to request that we enable pushing for "reasonably sized" >> breaking changes way more often. >> >> (where reasonably sized means touches exposed internals/structure in >> such a way that it wont affect normal users, but might affect plugins >> that are deeply involved) >> >> (examples of this are dropping support for the config/session parameters >> for node constructors, changing the behavior of the node-id creation, >> changing the config object initialization lifecycle/state management). >> >> >> And additionally i want to request dropping the feature branch mechanism >> in order to get a much tighter feedback loop on the changes going in. >> >> >> -- 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 Mon Nov 25 12:13:38 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Mon, 25 Nov 2019 09:13:38 -0800 Subject: [pytest-dev] Requesting a change of our deprecation policy and the potentially removal of the features branch In-Reply-To: References: Message-ID: I would also be ok with removing the master/features setup -- I think a few things would have to be carefully considered as part of releasing though: - some sort of marker to indicate (maybe just based on changelog filenames?) that a minor / patch / major release would be next - an overhaul of the various related documentation (how to release, PR changelog, probably some other stuff I'm forgetting about) I think as a result we'd also want to release more often (which I'm also not against). Anthony From opensource at ronnypfannschmidt.de Tue Nov 26 04:35:56 2019 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Tue, 26 Nov 2019 10:35:56 +0100 Subject: [pytest-dev] Requesting a change of our deprecation policy and the potentially removal of the features branch In-Reply-To: References: Message-ID: <24bd3338-5298-69ec-b05b-e1d001696f37@ronnypfannschmidt.de> * re-sent after sending the first one with the wrongsender* i'm planning to add town-crier support to the "guess next version" logic of setuptools_scm based on your pre-commit + potentially push action im hoping to provide 2 extra actions to provide better release automation a) regendoc autoproposal -> opens a pr when regendoc changes happen, updates it when new commits come in without merge b) next release proposal/merge -> runs town crier with the next version specified and publishes a branch/pr, auto-merges when a tagged version of that pr is deployed to pypi As part of implementing this proposal i would update the? related documentation -- Ronny Am 25.11.19 um 18:13 schrieb Anthony Sottile: > I would also be ok with removing the master/features setup -- I think > a few things would have to be carefully considered as part of > releasing though: > > - some sort of marker to indicate (maybe just based on changelog > filenames?) that a minor / patch / major release would be next > - an overhaul of the various related documentation (how to release, PR > changelog, probably some other stuff I'm forgetting about) > > I think as a result we'd also want to release more often (which I'm > also not against). > > Anthony > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From nicoddemus at gmail.com Tue Nov 26 10:00:24 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 26 Nov 2019 12:00:24 -0300 Subject: [pytest-dev] pytest 5.3.1 released Message-ID: pytest 5.3.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: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Felix Yan * Florian Bruhin * Mark Dickinson * Nikolay Kondratyev * Steffen Schroeder * Zac Hatfield-Dodds Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: