Mailman 3 October 2017 - pytest-dev

proposal - type-keyed storage for extension objects/metadata in config/items
by RonnyPfannschmidt Oct. 27, 2017

Oct. 27, 2017

hi everyone since a while now i feel the lack of a place where i can store objects that belong to some pytest plugin but shouldn't be plugins themselves i came up with an idea for a basic api and would like to get feedback from it at the basic level there would be a `config.objects` or `item.objects` as "immutable" mapping with 4 extra methods to mutate, i#ll just show the proposed effects get_or_create(tp, *k, **kw): if tp not in self: self[tp] = tp(*k, **kw) return self[tp] create(self, tp, *k, **kw): if tp in self: raise KeyError(tp) self[tp] = tp(*k, **kw) return self.tp add(obj): tp = type(obj) if tp in self: raise KeyError(tp) self[tp] = obj remove(self, obj): del self[type(obj)] discard(self, obj): self.pop(type(obj), None) by adding such a storage it will be a lot more easy to just put things on items and reports -- Ronny

3 2

deprecating `pytest_plugins` in non-initial conftests to prevent unintended smear/spill of plugin configurations
by RonnyPfannschmidt Oct. 25, 2017

Oct. 25, 2017

hi everyone, while reviewing the codebase i noticed, that the code that is ensuring we don't use conftests from other folders don't take into account `pytest_plugins` declared in such a conftest thus the plugin system gives a false impression. intuitively i'd expect plugins listed in a conftest only to be active when that conftest is active however due to the way our plugin system works, we only mark conftests of other folders as "disabled" not their dependencies i dont see a sane way to implement this feature correctly, as we wouldnt be allowed to disable a plugin just because its listed in one folder, after all it may be listed in multiple folders but not one certain folder the plugin system as we constructed is is not aware of hierarchical dependencies and i dont think we can get this good/right with the current development process we use as such i propose deprecating them and warning users about the problems with regard to when and how to warn we need to take a look in detail as there are many reasonably valid setups with exactly one non initial conftest and we should help people to turn those into initial conftest's while cleaning out the rest. -- Ronny

3 2

Garbage collection and pytest fixtures
by Dan Nealschneider Oct. 8, 2017

Oct. 8, 2017

Hey all- I've been exploring some of our tests that use a lot of memory, and whose memory use seems to grow over the course of a test run. In my preliminary investiagtion it seems like some of the memory use can be attributed to fixtures which create large objects. I'm using py.test 3.1.3 in python 2.7.13. We have a bunch of conftests and a local pytest plugin that changes some behaviors, so I want to check in about intended behavior before I go further. If I have a fixture like the following, should I expect the object returned by the fixture to be garbage collected after the tests that use it complete? Or after all the tests in the module complete? Or after the seesion completes? @pytest.fixture(scope='module') def big_item(): return [0] *1000000 Is this a reasonable way to use a fixture, or is there a better way to reuse a large and expensive-to-create item across tests? Thanks, Dan N

2 1

Pytest 3.2.3 released
by Bruno Oliveira Oct. 4, 2017

Oct. 4, 2017

Howdy everyone, pytest 3.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 http://doc.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Bruno Oliveira * Evan * Joe Hamman * Oliver Bestwalter * Ronny Pfannschmidt * Xuan Luong Happy testing, The pytest Development Team

1 0