I started by moving it from Python 2 to Python 3.9. Then the wxPython GUI needed to move up a few versions, but it wasn’t working too well. So I built a new browser-based user interface. A compute server in FastAPI and a UI in vanilla JavaScript are the new GUI.
There are features from the old GUI that aren’t available yet (You Are Here is my favorite), but it’s very usable.
The version bump to 6.0 is because I’ve dropped support for Python 2 and Python 3.5. But also because the changes to how third-party code is handled felt potentially disruptive. Please read that blog post for details.
The other big thing happening with coverage.py is Python 3.10. Because of PEP 626 (“Precise line numbers for debugging and other tools”), there have been many changes to how Python reports line numbers. Coverage.py depends on those line numbers, so there have been more than a few bug reports written against Python as the work has progressed.
It will be important to test with 3.10, but to be fair, there have already been a few problems reported in the latest version, 3.10 beta 4. So if you use beta 4, you’ll want to avoid re-reporting the known problems:
If you can build 3.10 from source, that would be a great thing to use for testing, or get ready to jump on 3.10.0 rc1 when it comes out on August 2.
Thanks!
]]>I’ve long been fascinated by stellation, the process of extending a polyhedron’s faces to form new structures. The word stellation is from the Latin root for star, so it means to make star-like. The star that graces the upper-left corner of this site is a stellated dodecahedron.
To understand stellations, let’s start with two dimensions. Consider a regular pentagon. If we extend the sides of the pentagon, they will intersect again, making a five-pointed star:
(image from brilliant.org.)
Looked at this way, the original pentagon is just the first 2D area enclosed by the sides’ five infinite lines. When we extend the sides, we’re finding five more areas (the points) enclosed by those same five lines. The five-pointed star is a stellation of the pentagon.
With a pentagon, there are no more stellations: extending the sides even more won’t find any more intersections, so no new areas are enclosed. But more complex shapes can have more stellations. As an example, a 9-sided polygon will have three stellations in sequence:
(image by Tomruen, CC BY-SA 3.0, via Wikimedia Commons.)
Going to three dimensions, stellating a polyhedron doesn’t extend edges, it extends faces. Here’s a video my son Ben made showing a dodecahedron producing three stellations. The faces each lie in one of 12 infinite planes, which intersect in a few different ways, producing new shapes:
The 12-sided dodecahedron only has those three stellations. Extending the planes further doesn’t produce any more intersections, so no new volumes are enclosed. The star on this site is the last (third) stellation of the dodecahedron.
What about the 20-sided icosahedron, how many stellations does it have? Things get much more complicated. In 1938, H.S.M. Coxeter and his co-authors wrote a famous book about the enumeration of the icosahedron’s stellations. First, rules had to be considered about what would count as a stellation, and what would not.
Like the 9-sided polygon, the dodecahedron has a simple linear sequence of stellations, each building on the previous, like nested Russian dolls. But the icosahedron is not so tidy. The book describes intricate rules that I won’t get into for determining what would be considered a stellation.
They counted 58 stellations of the icosahedron. When you include the original icosahedron itself in the list, you get the title of the book: The Fifty-Nine Icosahedra.
Jan Albert Vroegop has a beautiful gallery of all 59, but here is a sampling (from Maurice Starck’s page):
BTW, you can buy 3D-printed stellations, but trigger warning: some of them are called icosahedra when they are really dodecahedra!
]]>I’m not going to try to recap what happened in detail, but I can give you my overall perspective on it. The new owners started on the wrong foot, and then mishandled every subsequent interaction. At every turn, people feared the new owners and staff were going to do something malicious. Then something bad would happen, people would say, “look: malice!,” and the new staff would say, “it wasn’t malice, it was a mistake!” Then it would happen again.
A month ago, when the new trends were becoming clear, the operators of the #python channel (including me) decided to move #python to the new Libera.chat network being run by the old Freenode staff. But we also stayed in the Freenode channel to let people know where everyone had gone.
Yesterday, after a heated debate in the Freenode channel where I was accused of splitting the community, I got k-lined (banned entirely from Freenode). The reason given was “spamming”, because of my recurring message about the move to Libera. Then the entire Freenode #python channel was closed. So much for caring about the community.
Was it malice or was it mistake? Does it matter? It’s not a good way to run a network. After the channel was closed, people asking staff about what happened were banned from asking. That wasn’t a mistake.
I can’t claim to know the minds of the new Freenode owners or staff. All I can do is see their actions, or I could until they banned me from Freenode. I know that some of the new staff are people we had come to know over the years as persistent disrupters in #python. The people advocating for the new Freenode staff seem to trend towards the anti-code-of-conduct, “free speech means I don’t have to care” cohort. And the new staff seems to be using force to silence people asking questions. It’s clear that transparency is not a strong value for them.
Setting aside network drama, the big picture here is that the Freenode #python community isn’t split: it’s alive and well. It’s just not on Freenode anymore, it’s on Libera.
Freenode was a good thing. But the domain name of the server was the least important part of it, just a piece of technical trivia. There’s no reason to stick with Freenode just because it is called Freenode. As with any way of bringing people together, the important part is the people. If all of the people go someplace else, follow them there, and continue.
See you on Libera.
]]>Git has three different ways to finish up a pull request, which complicates the process of figuring out what to cherry-pick. Before getting into cherry-picking, let’s look at the three finishes to pull requests. Suppose we have four commits on the main branch (A-B-C-D), and a pull request for a feature branch started from B with two commits (F-G) on it:
The F-G pull request can be brought into the main branch in three ways. First, the F-G commits can be merged to main with a merge commit:
Second, the two commits can be rebased onto main as two new commits Fr-Gr (for F-rebased and G-rebased):
Lastly, the two commits can be squashed down to one new commit FGs (for F and G squashed):
Note that for rebased and squashed pull requests, the original commits F-G will not be reachable from the main branch, and will eventually disappear from the repo, indicated by their dashed outlines.
Now let’s consider the release branch. This is a branch made twice a year to mark community releases of the platform. Once the branch is made, some fixes need to be cherry-picked onto it from the main branch. We can’t just merge the fixes, because that would bring the entire history of the main branch into the release. Cherry-picking lets us take just the commits we want.
As an example, here E has been cherry-picked as Ec:
The question now is:
To get the changes from a finished pull request onto the release branch, what commits should we cherry-pick?
The two rules are:
GitHub doesn’t record what approach was used to finish a pull request (unless I’ve missed something). It records what it calls the “merge commit”. For merged pull request, this is the actual merge commit. For rebased and squashed pull requests, it’s the final commit that ended up on the main branch.
In the case of a merged pull request, the answer is easy: cherry-pick the two original commits in the pull request. We can tell the pull request was merged because the merge commit (with a thicker outline) has two parents (it’s actually a merge):
But for rebased and squashed pull requests, the answer is not so simple. We can tell the pull request wasn’t merged, because the recorded “merge commit” isn’t a merge. Somehow we have to figure out how many commits starting with the merge commit are the right ones to take. For a rebased pull request we’d like to cherry-pick as many commits as the pull request had:
And for a squashed pull request, we want to cherry-pick just the one squashed commit:
But how to tell the difference between these two situations? I don’t know the best approach. Maybe comparing the commit messages? My first way was to look at the count of added and deleted lines. If the merge commit changes as many lines as the pull request as a whole, then just take that one commit. But that could be wrong if a rebased pull request had overlapping commits, and the last commit changed all the lines.
Is there some bit of information I’ve overlooked? Does git or GitHub have a way to unambiguously distinguish these cases?
]]>I recently saw this as someone’s avatar:
This is clearly the Mandelbrot fractal, but where is it? What coordinates and magnification? Without accompanying information, is it possible to find it? I’d like to explore that region, but how can I find it?
This problem reminds me of Shazam, the seemingly magical app that listens to what’s playing in your environment, and tells you what song it is.
Is there any way?
BTW, the way I solved this problem in my own long-neglected Mandelbrot explorer Aptus is to write data records into the PNG files it produces.
For example, you can download the image from the Aptus page, and use imagemagick to see what data it contains:
$ identify -verbose JamesGiantPeach_med.png
Image:
Filename: JamesGiantPeach_med.png
Format: PNG (Portable Network Graphics)
...
Properties:
Aptus State:
{
"Aptus State": 1,
"angle": 0.0,
"center": [-1.8605327723759248, -1.270334865601334e-05],
"continuous": true,
"diam": [1.788139343261719e-07, 1.788139343261719e-07],
"iter_limit": 999,
"mode": "mandelbrot",
"palette": [
["spectrum", {"l": [50, 150], "ncolors": 12}],
["stretch", {"hsl": true, "steps": 25}]
],
"palette_phase": 190,
"palette_scale": 1.0,
"size": [500, 370],
"supersample": 3
}
Software: Aptus 2.0
To prove it works, here is the same place with a different viewer, using a URL crafted from the data in the PNG.
Aptus also knows how to read these files, so you can open a PNG it produced, and you will be exploring where it was captured. It’s like jumping into a photo to visit the place it was taken. I used the same technique in Flourish.
Too bad more images don’t carry metadata to help you re-find their location in mathematical space.
]]>tl;dr: install this and let me know if you don’t like the results:pip install coverage==5.6b1
What’s changed? Previously, coverage.py didn’t understand about third-party code you had installed. With no options specified, it would measure and report on that code, for example in site-packages. A common solution was to use --source=. to only measure code in the current directory tree. But many people put their virtualenv in the current directory, so third-party code installed into the virtualenv would still get reported.
Now, coverage.py understands where third-party code gets installed, and won’t measure code it finds there. This should produce more useful results with less work on your part.
This was a bit tricky because the --source option can also specify an importable name instead of a directory, and it had to still measure that code even if it was installed where third-party code goes.
As of now, there is no way to change this new behavior. Third-party code is never measured.
This is kind of a big change, and there could easily be unusual arrangements that aren’t handled properly. I would like to find out about those before an official release. Try the new version and let me know what you find out:
pip install coverage==5.6b1
In particular, I would like to know if any of the code you wanted measured wasn’t measured, or if there is code being measured that “obviously” shouldn’t be. Testing on Debian (or a derivative like Ubuntu) would be helpful; I know they have different installation schemes.
If you see a problem, write up an issue. Thanks for helping.
]]>But then I wanted a filter with both an if-action, and an else-action. Worse, I wanted if-A, then do this, if-B, do this, else, do that. GMail filters just aren’t constructed that way. It was going to be a pain to set them up and maintain them.
Looking around for tools, I found gmail-britta, a Ruby DSL. This was the right kind of tool for me, except I don’t write Ruby. I hadn’t found gmail-yaml-filters, but I don’t think I want to write YAML.
gmail-tools looked promising, but my work GMail account wouldn’t let me follow its authentication steps. Honestly, I often run afoul of authentication when trying to use APIs. (See Support windows bar calendar for another project I built in a strange way specifically to avoid having to figure out authentication.)
So naturally, I built my own module to do it: Gefilte Fish is a Python DSL (domain-specific language) of sorts to create GMail filters. (The name is fitting since this is the start of Passover.) Using gefilte, you write Python code to express your filters. Running your program outputs XML that you then import into GMail to create the filters.
The DSL lets you write this to make filters:
from gefilte import GefilteFish
# Make the filter-maker and use its DSL. All of the methods of GitHubFilter
# are now usable as global functions.
fish = GefilteFish()
with fish.dsl():
# Google's spam moderation messages should never get sent to spam.
with replyto("noreply-spamdigest@google.com"):
never_spam()
mark_important()
# If the subject and body have these, label it "liked".
with subject(exact("[Confluence]")).has(exact("liked this page")):
label("liked")
with from_("notifications@github.com"):
# Skip the inbox (archive them).
skip_inbox().label("github")
# Delete annoying bot messages.
with from_("renovate[bot]"):
delete()
# GitHub sends to synthetic addresses to provide information.
with to("author@noreply.github.com"):
label("mine").star()
# Notifications from some repos are special.
with repo("myproject/tasks") as f:
label("todo")
with f.elif_(repo("otherproject/something")) as f:
label("otherproject")
with f.else_():
# But everything else goes into "Code reviews".
label("Code reviews")
# Some inbound addresses come to me, mark them so
# I understand what I'm # looking at in my inbox.
for toaddr, the_label in [
("info@mycompany.com", "info@"),
("security@mycompany.com", "security@"),
("con2020@mycompany.com", "con20"),
("con2021@mycompany.com", "con21"),
]:
with to(toaddr):
label(the_label)
print(fish.xml())
To make the DSL flow somewhat naturally, I definitely bent the rules on what is considered good Python. But it let me write succinct descriptions of the filters I want, while still having the power of a programming language.
]]>Here’s what happened: I added a new parameterized test to the coverage.py test suite. It was really slow, so I ran it with timings displayed:
$ tox -qe py39 -- -n 0 -k virtualenv --durations=0 -vvv
... output omitted ...
========================= slowest test durations ==========================
7.14s call tests/test_process.py::VirtualenvTest::test_making_virtualenv[False]
6.23s call tests/test_process.py::VirtualenvTest::test_making_virtualenv[True]
0.47s setup tests/test_process.py::VirtualenvTest::test_making_virtualenv[False]
0.01s setup tests/test_process.py::VirtualenvTest::test_making_virtualenv[True]
0.01s setup tests/test_process.py::VirtualenvTest::test_making_virtualenv[False]
0.01s setup tests/test_process.py::VirtualenvTest::test_making_virtualenv[True]
0.00s teardown tests/test_process.py::VirtualenvTest::test_making_virtualenv[True]
0.00s teardown tests/test_process.py::VirtualenvTest::test_making_virtualenv[True]
0.00s teardown tests/test_process.py::VirtualenvTest::test_making_virtualenv[False]
0.00s teardown tests/test_process.py::VirtualenvTest::test_making_virtualenv[False]
========================= short test summary info =========================
FAILED tests/test_process.py::VirtualenvTest::test_making_virtualenv[False] ...
FAILED tests/test_process.py::VirtualenvTest::test_making_virtualenv[True] ...
Huh, that’s weird: two tests (“call”), but four invocations of my test setup function, and four to the teardown. I’ve only just recently converted this test suite over from a unittest.TestCase foundation, and I have some odd shims in place to reduce the code churn. Thinking about the double-setup, I thought either my shims were wrong, or I was in some strange edge case in how pytest runs tests.
But how to figure out why the setup is called twice for each test run? I decided to use a tool I’ve reached for often in the past: capture the stack information and record it someplace:
def setup_test(self):
import inspect
project_home = "/Users/ned/coverage"
site_packages = ".tox/py39/lib/python3.9/site-packages/"
with open("/tmp/foo.txt", "a") as foo:
print("setup_test", file=foo)
for t in inspect.stack()[::-1]:
# t is (frame, filename, lineno, function, code_context, index)
frame, filename, lineno, function = t[:4]
filename = os.path.relpath(filename, project_home)
filename = filename.replace(site_packages, "")
show = "%30s : %s:%d" % (function, filename, lineno)
print(show, file=foo)
This is my test setup function which is being called too often. I used a low-tech logging technique: append to a temporary file. For each frame in the call stack, I write the function name and where it’s defined. The file paths are long and repetitive, so I make them relative to the project home, and also get rid of the site-packages path I’ll be using.
This works, it gave me four stack traces, one for each setup call. But all four were identical:
setup_test
<module> : igor.py:424
main : igor.py:416
do_test_with_tracer : igor.py:216
run_tests : igor.py:133
main : _pytest/config/__init__.py:84
__call__ : pluggy/hooks.py:286
_hookexec : pluggy/manager.py:93
<lambda> : pluggy/manager.py:84
_multicall : pluggy/callers.py:187
pytest_cmdline_main : _pytest/main.py:243
wrap_session : _pytest/main.py:206
_main : _pytest/main.py:250
__call__ : pluggy/hooks.py:286
_hookexec : pluggy/manager.py:93
<lambda> : pluggy/manager.py:84
_multicall : pluggy/callers.py:187
pytest_runtestloop : _pytest/main.py:271
__call__ : pluggy/hooks.py:286
_hookexec : pluggy/manager.py:93
<lambda> : pluggy/manager.py:84
_multicall : pluggy/callers.py:187
pytest_runtest_protocol : flaky/flaky_pytest_plugin.py:94
pytest_runtest_protocol : _pytest/runner.py:78
runtestprotocol : _pytest/runner.py:87
call_and_report : flaky/flaky_pytest_plugin.py:138
call_runtest_hook : _pytest/runner.py:197
from_call : _pytest/runner.py:226
<lambda> : _pytest/runner.py:198
__call__ : pluggy/hooks.py:286
_hookexec : pluggy/manager.py:93
<lambda> : pluggy/manager.py:84
_multicall : pluggy/callers.py:187
pytest_runtest_setup : _pytest/runner.py:116
prepare : _pytest/runner.py:362
setup : _pytest/python.py:1468
fillfixtures : _pytest/fixtures.py:296
_fillfixtures : _pytest/fixtures.py:469
getfixturevalue : _pytest/fixtures.py:479
_get_active_fixturedef : _pytest/fixtures.py:502
_compute_fixture_value : _pytest/fixtures.py:587
execute : _pytest/fixtures.py:894
__call__ : pluggy/hooks.py:286
_hookexec : pluggy/manager.py:93
<lambda> : pluggy/manager.py:84
_multicall : pluggy/callers.py:187
pytest_fixture_setup : _pytest/fixtures.py:936
call_fixture_func : _pytest/fixtures.py:795
connect_to_pytest : tests/mixins.py:33
setup_test : tests/test_process.py:1651
I had hoped that perhaps the first and second calls would have slightly different stack traces, and the difference would point me to the reasons for the multiple calls. Since the stacks were the same, there must be loops involved somewhere. How to find where in the stack they were?
If I were familiar with the code in question, reading one stack trace might point me to the right place. But pytest is opaque to me, and I didn’t want to start digging in. I’ve got a few different pytest features at play here, so it seemed like it was going to be difficult.
The stack traces were the same, because they only show the static aspects of the calls: who calls who, from where. But the stacks differ in the specific instances of the calls to the functions. The very top frame is the same (there’s only one execution of the main program), and the very bottom frame is different (there are four executions of my test setup function). If we find the highest frame that differs between two stacks, then we know which the loop is calling the setup function twice.
My first thought was to show the id of the frame objects, but ids get reused as objects are reused from free-lists. Instead, why not just tag them explicitly? Every frame has its own set of local variables, stored in a dictionary attached to the frame. I write an integer into each frame, which is the number of times we’ve seen that frame.
Now the loop over frames also checks the locals of each frame. If our visit count isn’t there, initialize it to zero, and if it is there, increment it. The visit count is added to the stack display, and we’re good to go:
def setup_test(self):
import inspect
project_home = "/Users/ned/coverage"
site_packages = ".tox/py39/lib/python3.9/site-packages/"
with open("/tmp/foo.txt", "a") as foo:
print("setup_test", file=foo)
for t in inspect.stack()[::-1]:
# t is (frame, filename, lineno, function, code_context, index)
frame, filename, lineno, function = t[:4]
visits = frame.f_locals.get("$visits", 0) ## new
frame.f_locals["$visits"] = visits + 1 ## new
filename = os.path.relpath(filename, project_home)
filename = filename.replace(site_packages, "")
show = "%30s : %d %s:%d" % (function, visits, filename, lineno)
print(show, file=foo)
Now the stacks are still the same, except the visit counts differ. Here’s the stack from the second call to the test setup:
setup_test
<module> : 1 igor.py:424
main : 1 igor.py:416
do_test_with_tracer : 1 igor.py:216
run_tests : 1 igor.py:133
main : 1 _pytest/config/__init__.py:84
__call__ : 1 pluggy/hooks.py:286
_hookexec : 1 pluggy/manager.py:93
<lambda> : 1 pluggy/manager.py:84
_multicall : 1 pluggy/callers.py:187
pytest_cmdline_main : 1 _pytest/main.py:243
wrap_session : 1 _pytest/main.py:206
_main : 1 _pytest/main.py:250
__call__ : 1 pluggy/hooks.py:286
_hookexec : 1 pluggy/manager.py:93
<lambda> : 1 pluggy/manager.py:84
_multicall : 1 pluggy/callers.py:187
pytest_runtestloop : 1 _pytest/main.py:271
__call__ : 1 pluggy/hooks.py:286
_hookexec : 1 pluggy/manager.py:93
<lambda> : 1 pluggy/manager.py:84
_multicall : 1 pluggy/callers.py:187
pytest_runtest_protocol : 1 flaky/flaky_pytest_plugin.py:94
pytest_runtest_protocol : 0 _pytest/runner.py:78
runtestprotocol : 0 _pytest/runner.py:87
call_and_report : 0 flaky/flaky_pytest_plugin.py:138
call_runtest_hook : 0 _pytest/runner.py:197
from_call : 0 _pytest/runner.py:226
<lambda> : 0 _pytest/runner.py:198
__call__ : 0 pluggy/hooks.py:286
_hookexec : 0 pluggy/manager.py:93
<lambda> : 0 pluggy/manager.py:84
_multicall : 0 pluggy/callers.py:187
pytest_runtest_setup : 0 _pytest/runner.py:116
prepare : 0 _pytest/runner.py:362
setup : 0 _pytest/python.py:1468
fillfixtures : 0 _pytest/fixtures.py:296
_fillfixtures : 0 _pytest/fixtures.py:469
getfixturevalue : 0 _pytest/fixtures.py:479
_get_active_fixturedef : 0 _pytest/fixtures.py:502
_compute_fixture_value : 0 _pytest/fixtures.py:587
execute : 0 _pytest/fixtures.py:894
__call__ : 0 pluggy/hooks.py:286
_hookexec : 0 pluggy/manager.py:93
<lambda> : 0 pluggy/manager.py:84
_multicall : 0 pluggy/callers.py:187
pytest_fixture_setup : 0 _pytest/fixtures.py:936
call_fixture_func : 0 _pytest/fixtures.py:795
connect_to_pytest : 0 tests/mixins.py:33
setup_test : 0 tests/test_process.py:1651
The 1’s are frames that were the same from the first call to the second, and the 0’s are new frames. We can clearly see that flaky_pytest_plugin.py has the loop that calls the setup a second time.
Typical: once you know the answer, it’s obvious! I use the pytest-flaky plugin to automatically retry tests that fail. My new slow test isn’t just slow, it’s also a failing test (for now). So pytest-flaky is running it again.
The real mystery isn’t why the setup is called twice, but why the actual run of the test is only reported once. I checked: it’s not just the setup that runs twice, the body of the test is also running twice.
When I made the test pass, the double execution went away, because pytest-flaky wasn’t re-running the failed test.
This is a classic machete-mode debugging story: the problem was easier to dissect with dynamic tools rather than static; I hacked in some gross code to get me the information I needed; I didn’t know if it would work well, but it did.
BTW, it seems a bit presumptuous to promote this column of numbers to a “visualization,” but it is a good way to see the looping nature of the test runner. Here’s the fourth call stack:
setup_test
<module> : 3 igor.py:424
main : 3 igor.py:416
do_test_with_tracer : 3 igor.py:216
run_tests : 3 igor.py:133
main : 3 _pytest/config/__init__.py:84
__call__ : 3 pluggy/hooks.py:286
_hookexec : 3 pluggy/manager.py:93
<lambda> : 3 pluggy/manager.py:84
_multicall : 3 pluggy/callers.py:187
pytest_cmdline_main : 3 _pytest/main.py:243
wrap_session : 3 _pytest/main.py:206
_main : 3 _pytest/main.py:250
__call__ : 3 pluggy/hooks.py:286
_hookexec : 3 pluggy/manager.py:93
<lambda> : 3 pluggy/manager.py:84
_multicall : 3 pluggy/callers.py:187
pytest_runtestloop : 3 _pytest/main.py:271
__call__ : 1 pluggy/hooks.py:286
_hookexec : 1 pluggy/manager.py:93
<lambda> : 1 pluggy/manager.py:84
_multicall : 1 pluggy/callers.py:187
pytest_runtest_protocol : 1 flaky/flaky_pytest_plugin.py:94
pytest_runtest_protocol : 0 _pytest/runner.py:78
runtestprotocol : 0 _pytest/runner.py:87
call_and_report : 0 flaky/flaky_pytest_plugin.py:138
call_runtest_hook : 0 _pytest/runner.py:197
from_call : 0 _pytest/runner.py:226
<lambda> : 0 _pytest/runner.py:198
__call__ : 0 pluggy/hooks.py:286
_hookexec : 0 pluggy/manager.py:93
<lambda> : 0 pluggy/manager.py:84
_multicall : 0 pluggy/callers.py:187
pytest_runtest_setup : 0 _pytest/runner.py:116
prepare : 0 _pytest/runner.py:362
setup : 0 _pytest/python.py:1468
fillfixtures : 0 _pytest/fixtures.py:296
_fillfixtures : 0 _pytest/fixtures.py:469
getfixturevalue : 0 _pytest/fixtures.py:479
_get_active_fixturedef : 0 _pytest/fixtures.py:502
_compute_fixture_value : 0 _pytest/fixtures.py:587
execute : 0 _pytest/fixtures.py:894
__call__ : 0 pluggy/hooks.py:286
_hookexec : 0 pluggy/manager.py:93
<lambda> : 0 pluggy/manager.py:84
_multicall : 0 pluggy/callers.py:187
pytest_fixture_setup : 0 _pytest/fixtures.py:936
call_fixture_func : 0 _pytest/fixtures.py:795
connect_to_pytest : 0 tests/mixins.py:33
setup_test : 0 tests/test_process.py:1651
The 3’s change to 1’s at _pytest/main.py:271, which is the loop over the tests to run. Cool :)
]]>